babel.dates.parse_date() doesn't allow you to specify a format/pattern

[johanndt]

We've started using Babel recently but ran into an issue where babel.dates.parse_date() doesn't allow us to specify the format to use. It always uses the 'medium' format. And for some formats that fails. Eg. when using 'en_ZA', you can't parse a short format date.

Internally the first thing it does is call get_date_format() without being explicit about the format, thus the default 'medium' format always gets used.

I'm happy to submit a pull-request but need some guidance on what type of fix would be acceptable. To stick with the signature order used everywhere else would require a change to parse_date(string, format='medium', locale=LC_TIME) but this would break people's code who were using only 2 positional arguments.

Can we add it at the end eg. parse_date(string, locale=LC_TIME, format='medium')?

Or should we create a new function eg: parse_formatted_date(string, format='medium', locale=LC_TIME)? The existing function name can then just be a wrapper around the new function.

Hope all this made sense. Thanks!

[jtwang]

+1

We ran into this too and hacked around it and I never got around to logging an issue for it. ^_^

I like the approach of adding a kwarg to the existing parse_date fn. It nicely mirrors format_date.

[johanndt]

@jtwang you should see our hackish workaround! Monkey patching get_date_format in the library with a partial to always return the format we want. :)

[akx]

Since we're aiming for 3.0 next (at least that's in my plans :D) and API compatibility is not guaranteed, I think for symmetry/consistency locale should remain the last parameter, and format added before it.

[akx]

Also, I believe people mostly use the locale=... kwarg form to pass the locale in to Babel anyway :)

[johanndt]

Thanks @akx. So if we aim for 3.0 should the PR just be against master?

[akx]

Sure, @johanndt :) And thanks in advance!