#24955: Allow BC dates and > 10000 years in Django ORM & forms
----------------------------------------------+--------------------
Reporter: BertrandBordage | Owner: nobody
Type: New feature | Status: new
Component: Database layer (models, ORM) | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
Currently, the minimum date we can use in Django is {{{0001-01-01}}}.
However, some databases allow before Christ dates, extremely useful for
historic projects.
In a same fashion, some databases allow dates greater than
{{{9999-12-31}}}, while Django limits year format to a 4-digits number.
Of course, this assumes that all dates are defined using
[http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar the proleptic
Gregorian calendar].
Here’s the DB support:
* PostgreSQL uses the format {{{0001-01-01 BC}}}. Dates can go from
{{{4714-11-24 BC}}} to {{{5874897-12-31}}}. That minimum date follows the
suggestion of [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601] for the
minimum date of the proleptic Gregorian calendar.
* SQLite uses the format {{{-0001-01-01}}}. Dates can go from
{{{-9999-01-01}}} to {{{9999-12-31}}} if you use the {{{date}}} function
before inserting data. However, since SQLite is a scam and has absolutely
no constraint, you can store {{{-9999999-13-32}}} as well as {{{SQLite is
a traitor, don’t use it to store important data}}} in a date column.
* MySQL has no BC support. According to the docs, dates can go from
{{{1000-01-01}}} to {{{9999-12-31}}}, but it also states that “although
earlier values might work, there is no guarantee”. In practice, we can use
dates from {{{0001-01-01}}} to {{{1000-01-01}}}, but we shouldn’t. Another
insanity: you can use the format {{{0001-01-01 BC}}} format. As usual,
MySQL will react in the stupidest way possible: it ignores what you write
after the date. You can even write {{{0001-01-01MySQL is rubbish, don’t
use it}}}, it’ll happily answer {{{0001-01-01}}}.
* Oracle seems to support {{{BC}}} and {{{B.C.}}} mentions in its
{{{TO_DATE}}} function, as well as a {{{S0001}}} format for years before
Christ.
In order to resolve this issue, we need to decide how to write BC dates in
the ORM and in the admin. I’m in favor of a +/- notation before the year,
more natural to me. It’s also suggested by ISO 8601. And it means we don’t
have to localize that 'BC' mention. I’m aware that this +/- notation is
not ideal because of the other minuses used as separators, but that seems
like the best choice anyway.
The first component to change in order to resolve this issue is of course
the ORM. Changing the forms will then be easy.
----
Sources:
* PostgreSQL: interacting with the DB +
http://www.postgresql.org/docs/9.4/static/datatype-datetime.html
* SQLite: interacting with the DB
* MySQL: interacting with the DB +
https://dev.mysql.com/doc/refman/5.7/en/datetime.html
* Oracle: http://www.techonthenet.com/oracle/functions/to_date.php
--
Ticket URL: <https://code.djangoproject.com/ticket/24955>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/058.83bb3d243680e984e6ffd68a3236c931%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
