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

Guido van Rossum guido at python.org
Sat Jun 9 05:06:33 CEST 2012

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)

More information about the Python-Dev mailing list