[Python-Dev] TZ-aware local time

[Guido van Rossum]

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)