datetime_safe should zero-pad old years

[Eric Floehr <eric@…>]

Datetime_safe, introduced as a result of #1443 due to strftime's limitation on years prior to 1900, does not zero-pad years with the %Y format.

I believe that the intent of %Y is to provide a 4-digit year, so years like 234 should be represented 0234, and 20 should be 0020. This is how %Y works in languages that support years less than 1900. (Rant: Why is python so behind on this, we shouldn't even have to worry about this!)

However, practically, the implementation as it exists will cause incorrect dates to be inserted into most databases.

For example begin_date=date(1,1,1), end_date=date(1948,12,31) causes the following insert to get generated:

INSERT INTO "test_table" ("begin_date", "end_date") VALUES (E'   1-01-01', E'1948-12-31')

PostgreSQL, and most other databases, will interpret a one- and two-digit years as centered around the 1900's or 2000's, and in fact PostgreSQL specifically will interpret '1-01-01' as '2001-01-01'.

It should more properly generate the following:

INSERT INTO "test_table" ("begin_date", "end_date") VALUES (E'0001-01-01', E'1948-12-31')

The change is adding a zero to the format string in datetime_safe's strftime, and adding a doctest to ensure. I've attached the diff file from changeset:10581.

I do not believe there are any negative consequences to this change.

[Eric Floehr <eric@…>]

svn diff to add zero-padding to %Y in datetime_safe, along with doctest addition

[Eric Floehr <eric@…>]

[corrected -- ran diff twice in first one] svn diff to add zero-padding to %Y in datetime_safe, along with doctest addition

[Karen Tracey]

#11132 reported this as old dates output by dumpdata cannot be loaded by loaddata, and proposed the same patch.

[Eric Floehr <eric@…>]

This ticket, and its patch, appears to have been incorporated in trunk, as part of the fix for #12524, so this ticket can be closed.

[Karen Tracey]

Fixed in r12423/r12424. (Note anyone could close the ticket -- special privs are not needed for that.)