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
10866	datetime_safe should zero-pad old years	Eric Floehr <eric@…>	nobody	"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.
"		closed	Core (Other)	dev		fixed	datetime_safe date datetime		Ready for checkin	1	0	0	0	0	0