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

Guido van Rossum guido at python.org
Mon Jun 11 20:55:27 CEST 2012

Let's agree to disagree. I don't have the time to argue any more but you haven't convinced me.

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

On Mon, Jun 11, 2012 at 1:01 PM, Guido van Rossum <guido at python.org> wrote: ..

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

No.  "Seconds since epoch" or "POSIX" timestamp is a foreign data type to the datetime module.  An aware datetime object with tzinfo=timezone.utc or a naive datetime object representing UTC time by convention is the datetime module way to represent absolute time. If I need to convert time obtained from an e-mail header or a log file to local time, I don't want to go through a  "POSIX" timestamp.  I want the obvious code to work correctly:

t = datetime.strptime(timestring, format) localtimestring = datetime.localtime(t).strftime(format) (Note that the first statement already works in 3.2 if timezone information is compatible with %z format.) .. 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. I am not against adding LocalTimezone to datetime.  We can copy tzinfo-examples.py to datetime.py and call it the day.  However, this will not eliminate the need for the localtime() function. 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. I don't think I ever promoted this idea.  The time module has its uses, but ATM it does not completely solve the local time problem either.  See <http://bugs.python.org/issue1647654>. .. Users should be required to understand POSIX timestamps and the importance of UTC before they try to work with multiple timezones. I disagree.  First, UTC and POSIX timestamps are not the same thing. I am not talking about leap seconds or epoch.  I just find this: $ TZ=UTC date Mon Jun 11 18:15:48 UTC 2012 much easier to explain than this: $ TZ=UTC date +%s 1339438586 There is no need to expose developers of e-mail servers or log analytics to 9-10 digit integers or even longer floats.  Second, UTC is only special in the way that zero is special.  If you write a function converting incoming time string to local time, you don't need to special case UTC as long as incoming format includes explicit offset. And they should store timestamps as POSIX timestamps, not as datetime objects with an (implicit or explicit) UTC timezone. I disagree again.  At the end of the day, they should "store" timestamps in a human-readable text format.  For example, http://www.w3.org/TR/xmlschema-2/#isoformats Users who want an object that stores a POSIX timestamp internally, but presents rich date-time interface can use an excellent mxDateTime class. It is one thing to provide datetime.fromtimestamp() and datetime.timestamp() methods for interoperability, it is quite another thing to require users to convert their datetime instances to timestamp for basic timezone operations.

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

More information about the Python-Dev mailing list