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

[Walter Doekes]

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.

​https://github.com/django/django/blob/master/django/conf/locale/en/formats.py#L13
​https://github.com/django/django/blob/master/django/contrib/admin/static/admin/js/admin/DateTimeShortcuts.js#L330

Shouldn't formats.py 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..

[Tim Graham]

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

[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 widgets.py, 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'
  +DATE_OUTPUT_FORMAT = 'Y-m-d'
  ...
   DATE_INPUT_FORMATS = [
       '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y',  # '2006-10-25', '10/25/2006', '10/25/06'
  

[Tim Graham]

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.