Opened 16 years ago

Closed 16 years ago

#10603 closed (wontfix)

DateField DEFAULT_DATE_INPUT_FORMATS

Reported by: pcicman Owned by: nobody
Component: Forms Version: dev
Severity: Keywords: forms date time datetime format templates
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Wouldn't it be better to move DEFAULT_DATE_INPUT_FORMATS to settings.py?

DEFAULT_DATE_INPUT_FORMATS doesn't match for most European Countries, so only one way how to change it is putting format for every form field through input_formats argument, what's just not so nice.

Second problem is output (display) format of Date field. I think its similar to #3672. It just doesn't care of INPUT_FORMAT because its not implemented.

There are actually some formats available in settings.py, eg:

DATE_FORMAT = 'd.m.Y'
DATETIME_FORMAT = 'd.m.Y H:i'
TIME_FORMAT = 'H:i'
YEAR_MONTH_FORMAT = 'F Y'
MONTH_DAY_FORMAT = 'j. F'

which doesn't really make much sense.

PROPOSAL

Can't be this settings just combined together to one default date/time/datetime formats, which will be used for all date/time input/display?

In this case eg DATE_FORMAT can stay in settings.py, but should may be changed to tuple, which will contain one or more formats. For input, all formats will be available, for output will be by default taken the very first format.

I think this will make sense also for international pages, where will be still possible to provide different settings for different country/language/...

unicode for date/time then can also return right output string (formated). This may be very useful for rendering date/time in template.

Change History (1)

comment:1 by Malcolm Tredinnick, 16 years ago

Resolution: wontfix
Status: newclosed

This isn't the correct solution for this problem, since date input formats is a localisation issue, not something the installer of an application should configure in settings. Your approach also fails in the very common case when a site is available in more than one locale at a time.

The correct solution here is that those formats either have to be localised or (preferably) made available as metadata for each locale. That's something we're working on already -- providing sensible values for those things, as well as locale-aware validation for other form fields that change values.

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