datetime_safe should zero-pad old years
|Reported by:||Owned by:||nobody|
|Severity:||Keywords:||datetime_safe date datetime|
|Cc:||Triage Stage:||Ready for checkin|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
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.
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.
Change History (7)
comment:1 Changed 7 years ago by
|Component:||Uncategorized → Core framework|
|Patch needs improvement:||unset|