[Python-Dev] TZ-aware local time

[Guido van Rossum]

On Mon, Jun 11, 2012 at 7:10 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Alexander Belopolsky <alexander.belopolsky at gmail.com> writes:
>
>> 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.
>
> On this point I must agree with Alexander.
>
> Unambiguous storage of absolute time can be achieved with POSIX
> timestamps, but that is certainly not the only nor best way to do it.
>
> For example, RFC 5322 specifies a standard serialisation for timestamp
> values that is in very wide usage, and those values are valid for
> transforming to a ‘datetime.datetime’ value. POSIX timestamps are
> not a necessary part of the data model.

To the contrary, without the POSIX timestamp model to define the
equivalency between the same point in time expressed using different
timezones, sane comparisons and arithmetic on timestamps would be
impossible.

> Another example is database fields storing timestamp values; they are
> surely a very common input for Python ‘datetime.datetime’ values.

But how does a database represent timestamps *internally*?

And does it store the timezone or not? I.e. can it distinguish between
two representations of the *same* point in time using different
timezones? If so, how would queries work?

> For many use cases a different storage is appropriate, a different input
> is appropriate, and POSIX timestamps are irrelevant for those use cases.

POSIX timestamps are no good for human-entered input or human-readable
output. But they are hard to beat for internal storage.

>> > .. Users should be required to understand POSIX timestamps and the
>> > importance of UTC before they try to work with multiple timezones.
>
> Why? If they are using, for example, a PostgreSQL ‘TIMESTAMP’ object to
> store the value, and manipulating it with Python ‘datetime.datetime’,
> why should they have to know anything about POSIX timestamps?

So they'll understand that midnight in New York != midnight In San
Francisco, while 4pm in New York == 1pm in San Francisco. And so they
understand that, while the difference between New York and San
Francisco time is always 3 hours, the difference between San Francisco
time and Sydney time can vary by two hours.

> On the contrary, for such use cases (and database timestamp values are
> just one such) I think it's a needless imposition on the programmer to
> force them to learn about POSIX timestamps, a data type irrelevant for
> their purposes.

IMO you ignore the underlying POSIX timestamps at your peril as soon
as you are comparing timestamps.

Anyway, we're very far from the original problem statement. If the
requirement is to represent timestamps as found in email and be able
to reproduce them exactly, you may have to store the original string
beside some parsed-out version, since there are subtleties in the
string version that are lost in parsing. Hopefully the parsed-out
version can be represented as a tz-aware datetime, and hopefully for
most purposes that's all you need (if you don't need to be able to
verify a digital signature on the text of the headers). The fixed
timezones now in the stdlib are probably best for this. The rest would
seem to be specific to the email package.

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