Custom date formats and admin

[David Larlet]

Hello,

Today I tried to handle custom dates formats in admin and there are a
couple of issues related to that.

First on rendering, AdminDateWidget doesn't inherit from DateTimeInput
which seems more logic to me. I eventually update the patch #7656 and
it works. Is there any reason against that approach before I add tests
and documentation?

Then on validation, my first idea was to allow
form.fields.DEFAULT_DATE/TIME_INPUT_FORMATS to be overridden by
settings and I think it makes sense because from my experience, when
you decide to create a website (let's say, in French) you do not want
to pass your custom input_formats argument to all your fields. I know,
I can add a FRDate/TimeField in localflavor but it doesn't solve the
admin issue either. Are there drawbacks to this approach?

I know that the timing isn't that good because you are working on big
1.1 features but I need it now and I'll work on it so feedback is
appreciated before I submit complete patches.

Regards,
David

ps: looking for tickets on this topic, I found #8962 which is
interesting in terms of consistency, note that the author discuss the
interest of settings in comments too.

http://code.djangoproject.com/ticket/7656
http://code.djangoproject.com/ticket/8962

[Malcolm Tredinnick]

On Sat, 2009-02-07 at 12:35 +0100, David Larlet wrote:
[...]

> Then on validation, my first idea was to allow
> form.fields.DEFAULT_DATE/TIME_INPUT_FORMATS to be overridden by
> settings and I think it makes sense because from my experience, when
> you decide to create a website (let's say, in French) you do not want
> to pass your custom input_formats argument to all your fields. I know,
> I can add a FRDate/TimeField in localflavor but it doesn't solve the
> admin issue either. Are there drawbacks to this approach?

Yes, ideally, some subset of the input formats would be translated and
the form would carry some information about the language it expects to
process (which could well be different from the user's locale setting,
since the latter can change and the former won't necessarily). Providing
we make the default "en-us", that's all backwards compatible, too.

We might need to carry that information about what formats are
permissible outside of a PO file, though. Perhaps along with the
information I want to put into 1.1 on things like decimal-separator and
first-day-of-the-week. It's just that a Python list is a much more
natural way of describing that information than trying to force it into
msgid/msgstr format (although the latter is slightly more friendly for
no-think-mode for translators, but sometimes translators have to give a
little, too, since we go out of our way a lot for them already).

> I know that the timing isn't that good because you are working on big
> 1.1 features but I need it now and I'll work on it so feedback is
> appreciated before I submit complete patches.

The timing isn't too bad. Getting better i18n support for dates is
something I'm going to work more heavily on after the alpha release,
which could well mean reviewing a whole bunch of patches and applying
things.

Regards,
Malcolm