Opened 8 years ago

Last modified 8 years ago

#25024 new Cleanup/optimization

Discrepancy between /admin/ DateTimePicker.js date format and SHORT_DATE_FORMAT in /en/ lang

Reported by: Walter Doekes Owned by: nobody
Component: Internationalization Version: 1.8
Severity: Normal Keywords:
Cc: wjdoekes+django@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


A question:

DateTimeShortcuts.js uses get_format('DATE_INPUT_FORMATS')[0] while the rest of a Django application uses SHORT_DATE_FORMAT to format dates.

Shouldn't be adjusted so DATE_INPUT_FORMATS holds '%m/%d/%Y' which is equal to SHORT_DATE_FORMAT ('m/d/Y')?

Further, I believe that the datepicker ignores the USE_L10N setting as well (assuming it to be True). At least it used to in previous Django versions.

Not sure whether to categorize under i18n or admin..

Change History (3)

comment:1 Changed 8 years ago by Tim Graham

Could you clarify the current behavior vs. the expected behavior? Is the issue related to #23049?

comment:2 Changed 8 years ago by Walter Doekes

Hi tim, thanks for the quick response.

Related to #23049? Somewhat.

  • That ticket says: when changing DATE_INPUT_FORMATS, certain strftime-parameters are broken/unusable from Javascript.
  • This ticket says: the default DATE_INPUT_FORMATS does not match up with the default (SHORT_)DATE_FORMAT.

To clarify: DATE_INPUT_FORMATS is supposedly should be used as input, but it's also used for output: in DateTimeShortcuts.js and as default value in the DateInput widget.

Expected behaviour:

  • DateTimeShortcut datepicker uses (SHORT_)DATE_FORMAT.

Observed behaviour:

  • DateTimeShortcut datepicker and the DateInput widget use DATE_INPUT_FORMATS[0] (because of the strftime notation), but that zeroth value (%Y-%m-%d) is unequal to the default (SHORT_)DATE_FORMAT (m/d/Y). This becomes inconsistent when you want to format dates in other places using the |date filter.

Possible fix 1:

  • Sync the value with the SHORT_DATE_FORMAT.
    -    '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y',  # '2006-10-25', '10/25/2006', '10/25/06'
    +    '%m/%d/%Y', '%Y-%m-%d', '%m/%d/%y',  # '10/25/2006', '2006-10-25', '10/25/06'

Although the bug may be in wrongly using the *input* formats for *output*. So the better fix might be 2:

  • Use the output value instead of the zeroth element of allowed inputs.
    -            var format = get_format('DATE_INPUT_FORMATS')[0];
    +            var format = get_format('DATE_FORMAT'); /* or SHORT_DATE_FORMAT? */
    +            format = format.replace(/([A-Za-z])/g, '%$1');
    (and fixes for _format_value() in, so DATE_FORMAT is used as initial-value-format)

Possible fix 3:

  • Add a separate php-style date format for DATE_INPUTS_FORMATS[0], so I can consistently output values in the same format as the DateField widget, e.g.:
     DATE_FORMAT = 'N j, Y'
         '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y',  # '2006-10-25', '10/25/2006', '10/25/06'

comment:3 Changed 8 years ago by Tim Graham

Component: UncategorizedInternationalization
Triage Stage: UnreviewedAccepted
Type: BugCleanup/optimization

Well, these values are being formatted in input boxes so I don't think it's illogical to use DATE_INPUT_FORMATS. Maybe your idea of trying to use the value from SHORT_DATE_FORMAT has some merit, but we'll have to see a patch to assess feasibility and what complexity this might add. I'm not much of an expert in this area, but I'll tentatively accept the ticket pending input from others.

Note: See TracTickets for help on using tickets.
Back to Top