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

Guido van Rossum guido at python.org
Mon Jun 11 19:01:57 CEST 2012

On Mon, Jun 11, 2012 at 6:33 AM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:

On Fri, Jun 8, 2012 at 11:06 PM, Guido van Rossum <guido at python.org> wrote:

On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote: ..

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. .. I'm still unsure what problem you're trying to solve. The problem is: produce a timestamp (e.g.  RFC 3339) complete with timezone information corresponding to the current time or any other unambiguously defined time.  This is exactly what my proposed datetime.localtime() function does.

Maybe the problem here is the input? It should be a POSIX timestamp, not a datetime object.

Another approach might be to tweak the existing timetuple() API to properly compute the is_dst flag? It currently always seems to return -1 for that flag.

Can we just introduce LocalTimezone (or whatever name it should have) and let the issue rest? No.  LocalTimezone adresses a different problem and does not solve this one.  If you generate a timestamp using datetime.now(LocalTimezone).strftime("... %z"), your timestamps will be wrong for one hour every year.  Some users may tolerate this, but the problem is not hard to solve and I think datetime module should offer one obvious and correct way to do it.

Ok, I trust that LocalTimezone doesn't solve your problem. Separately, then, I still think we should have it in the stdlib, since it probably covers the most use cases besides the utc we already have.

PS. TBH I don't care for the idea that we should try to hide the time module and consider it a low-level implementation detail for the shiny high-level datetime module. The simply serve different purposes. Users should be required to understand POSIX timestamps and the importance of UTC before they try to work with multiple timezones. And they should store timestamps as POSIX timestamps, not as datetime objects with an (implicit or explicit) UTC timezone.

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

More information about the Python-Dev mailing list