id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
24955	Allow BC and > 10000 years dates in Django ORM & forms	Bertrand Bordage	nobody	"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"	New feature	closed	Database layer (models, ORM)	dev	Normal	wontfix			Unreviewed	0	0	0	0	0	0