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.
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.