[Python-Dev] TZ-aware local time

[Alexander Belopolsky]

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(time_string, format)
>>> local_time_string = 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.