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

Guido van Rossum guido at python.org
Tue Jun 12 06:17:46 CEST 2012

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)

More information about the Python-Dev mailing list