[Python-Dev] TZ-aware local time

[Ben Finney]

Guido van Rossum <guido at python.org> writes:

> On Mon, Jun 11, 2012 at 7:10 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> > 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.

Why is the POSIX timestamp model the only possible model? To the
contrary, there are many representations with different tradeoffs but
with the common properties you name (“equivalency between the same point
in time expressed using different timezones”).

I'm objecting to your assertion that the *specific* data format of POSIX
timestamps is necessary for this, rather than being a contingent format
that is one of many real world formats used for timestamps.

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

My point is that the programmer using Python ‘datetime’, and not dealing
with POSIX timestamps at any point, should not need to care how
‘datetime’ represents its values internally.

You said “the *input* […] should be a POSIX timestamp, not a datetime
object.”, but these use cases (RFC 5322 timestamps, database timestamp
field values) have other inputs for timestamp values and there's no need
for a POSIX timestamp in the data model.

The programmer for these common use cases is dealing with input that is
not POSIX timestamps, their output is not POSIX timestamps, and the data
processing doesn't have any need for the concept of “seconds since
epoch”. So why claim that the POSIX timestamp is necessary for such use
cases?

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

Perhaps so, and perhaps not. Either way, that's not an argument for
requiring the user of ‘datetime’ to deal with that internal
representation.

The ‘datetime’ module provides a useful abstraction that allows
different serialisation, without tying the programmer to POSIX
timestamps.

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

You made two assertions in “Users should be required to understand POSIX
timestamps and the importance of UTC before they try to work with
multiple timezones.”

I'm not objecting to “Users should be required to understand the
importance of UTC before they try to work with multiple timezones”.

I am objecting to “Users should be required to understand POSIX
timestamps before they try to work with multiple timezones”.

Your argument about timezones is irrelevant to my objection about
requiring users to understand POSIX timestamps.

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

If another representation (e.g. a database field) allows the comparison
safely, why require the programmer to understand a data representation
irrelevant to their use case?

> Anyway, we're very far from the original problem statement.

That might be part of the misunderstanding, and I apologise if that
confused matters.

I don't want a useful abstraction like Python's ‘datetime’ to be
intentionally leaky, so I don't think “Users should be required to
understand POSIX timestamps before they try to work with multiple
timezones” is helpful.

That's the whole of my objection, and the only point I'm currently
arguing in this wide-ranging thread.

-- 
 \              “Whatever you do will be insignificant, but it is very |
  `\                    important that you do it.” —Mohandas K. Gandhi |
_o__)                                                                  |
Ben Finney