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
32738	Deprecate django.utils.datetime_safe, use alternate method to ensure four-digit year with strftime.	Nick Pope	Nick Pope	"While working on #32366, I came across `django.utils.datetime_safe`. It exists to ensure that `%Y` for `datetime.datetime.strftime()` produces a correct zero-padded 4-digit year. It is only used in three places in Django: 

The module refers to https://bugs.python.org/issue13305. On reading further, I understand the following:

For years < 1000 specifiers `%C`, `%F`, `%G`, and `%Y` don't work as expected for `strftime` provided by glibc on Linux as they don't pad the year or century with leading zeros. Support for specifying the padding explicitly is available, however, which can be used to fix this issue, e.g. `%04Y`.
                    
FreeBSD, macOS, and Windows do not support explicitly specifying the padding, but return four digit years (with leading zeros) as expected.

It seems to me that the current approach is quite complex and that we could simply implement a check whether `%Y` produces the expected value and, if not, make the following substitutions:

- `%C` → `%02C`
- `%F` → `%010F`
- `%G` → `%04G` 
- `%Y` → `%04Y`

This changes from wrapping `date`/`datetime` objects in subclasses with overridden `.strftime()` to a simple function call to check whether we need to fix the format and rewrite the format if so. (This can be cached.) We also gain the benefit of fixing other specifiers that are also affected, rather than just `%Y`.

There has been some precedence for cleaning up `datetime_safe` in #29600. Also, Aymeric [https://code.djangoproject.com/ticket/21256#comment:1 doesn't really like it]... :D"	Cleanup/optimization	closed	Utilities	dev	Normal	fixed	datetime_safe, datetime		Accepted	1	0	0	0	0	0