[Python-Dev] TZ-aware local time

[Guido van Rossum]

On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Tue, Jun 5, 2012 at 6:07 PM, Guido van Rossum <guido at python.org> wrote:
>>> See http://bugs.python.org/issue9527 .

> With datetime.timestamp() method committed, I would like to get back
> to this issue.

What was committed? The bug only mentions a change to the email package.

> In some sense, an inverse of  datetime.timestamp() is
> missing from the datetime module.  Given a POSIX timestamp, I cannot
> get the local time as an aware datetime object.

But that's because there are (almost) no tz objects in the stdlib.

>> 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.
>
> A tzinfo subclass emulating local time rules introduces the DST
> ambiguity to a problem that does not inherently suffer from it.

But if you knew the name for the local time zone and constructed a
datetime using it (e.g. using the excellent pytz package) it would
suffer from exactly the same problem, wouldn't it? (Except on some
systems it might be more correct for historic dates when a different
algorithm was used.)

> See
> <http://bugs.python.org/issue9063>.  A typical application is an
> e-mail agent that has to insert local time complete with UTC offset in
> the message header.  The time.localtime() method will produce local
> time components together with the dst flag from which time.strftime()
> can produce RFC 3339 timestamp using "%z" directive.   There is no
> ambiguity during DST transition.  The only complication is that time
> component TZ components exhibit canceling discontinuities at those
> times.  For example,
>
>>>> t = mktime((2010, 11, 7, 1, 0, 0, -1, -1, 0))
>>>> for i in range(5):
> ...     print(strftime("%T%z", localtime(t + i - 2)))
> ...
> 01:59:58-0400
> 01:59:59-0400
> 01:00:00-0500
> 01:00:01-0500
> 01:00:02-0500
>
> As I explained at <http://bugs.python.org/msg109452>, it is not
> possible to reproduce this sequence using LocalTimezone.

So LocalTimezone (or any named timezone that uses DST) should not be
used for this purpose. That does not make LocalTimezone useless -- it
is no less useless than any DST-supporting timezone.

>> 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.
>
> We can avoid introducing new methods.  We can add aware= flag to
> datetime.now() and datetime.fromtimestamp(), but it may be better to
> introduce special values for existing tzinfo= argument instead.  For
> example, we can allow passing an empty string in tzinfo to signify
> that a timezone instance should be generated filled with appropriate
> local offset.  This choice may seem less of a hack if we introduce
> some simple TZ parsing and allow string values like "UTC-0500" as
> valid tzinfo specifications.

I'm still unsure what problem you're trying to solve. Can we just
introduce LocalTimezone (or whatever name it should have) and let the
issue rest?

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