[Python-Dev] TZ-aware local time (original) (raw)

Guido van Rossum guido at python.org
Wed Jun 6 00:07:21 CEST 2012

On Tue, Jun 5, 2012 at 11:29 AM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:

Changing subject to reflect a change of topic.

On Tue, Jun 5, 2012 at 2:19 PM, Guido van Rossum <guido at python.org> wrote: .. Although if we ever get that "local time" tzinfo object, we may regret it. So I propose to launch without it and see if people object. There simply isn't a way to roundtrip for times that fall in the DST->std transition, and I doubt that many users will want to think about it (they'd have to store an extra bit with all their datetime objects -- it would be better to get them to use tzinfo objects instead...). I've also been arguing against "local time" tzinfo

Why? I don't see your argumentation against such a tzinfo in the bug (but I may have missed it, it's a lot of comments).

and my proposal was to create a function that would produce TZ-aware local time with tzinfo bound to a fixed-offset timezone.  In New York that would mean EDT in the summer and EST in the winter.   This is what Unix date utility does.

See http://bugs.python.org/issue9527 .

I don't like that function. It returns two different timezone objects depending on whether DST is in effect. Also it adds a new method to the datetime class, which I think is unnecessary here. I understand returning two different timezone objects appear simpler, but it is also more limiting: there are things you can do with timezone objects that you can't do with these fixed-offset timezone objects, such as adding a timedelta that produces a result in a different DST state. E.g. adding 6 months to June 1st, 2012, PDT, would return Dec 1st, 2012, PDT, which is not local time here.

Reading the requirements for a timezone implementation and the time.localtime() function, it would seem that a timezone object representing "local time" can certainly be constructed, as long as the time module uses or emulates the Unix/C behavior. On platforms where it doesn't, it is okay to guess based on the limited information it does have. But it looks like it should work on Unix/Linux, Windows, and Mac. The crux is that the localtime() function "knows" the rules for local DST in the past and future. It is true that it may not always be right (e.g. if politics change the rules for the future, or if the algorithm used is simplified, making it incorrect for times far in the past), but it would still be consistent with the time module's notion of local time, and we can consider this a bug in the OS (or libc) rather than in Python.

If in the past I was ever opposed to that (as Raymond assumes in a comment in that issue) I have changed my mind, but I think it's more likely that we put off the creation of concrete timezone implementations until later and then got distracted -- after all we didn't even supply a UTC timezone, which surely is a lot simpler than the local timezone.

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list