Guido van Rossum <gu...@python.org> writes: > On Mon, Jun 11, 2012 at 7:10 PM, Ben Finney <ben+pyt...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
