[Python-Dev] TZ-aware local time

Ben Finney ben+python at benfinney.id.au
Tue Jun 12 04:10:36 CEST 2012


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.

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

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

> > .. 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?

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.

-- 
 \       “My business is to teach my aspirations to conform themselves |
  `\              to fact, not to try and make facts harmonise with my |
_o__)                   aspirations.“ —Thomas Henry Huxley, 1860-09-23 |
Ben Finney



More information about the Python-Dev mailing list