Ka-Ping Yee <pyt...@zesty.ca> added the comment:
I am extremely disappointed by what has happened here.
We are talking about a very simple method that everybody needs, and that has
been reimplemented over and over again. I have been frustrated countless times
by the lack of a utctotimestamp() method. I have watched beginners and
experienced programmers alike suffer over and over again for the lack of this
method, and spend hours trying to figure out why Python doesn't have it and how
it should be spelled in Python.
The discussion here has been stuck on assumptions that the method must meet all
of the following ideals:
1. It must produce a value that is easy to compute with
2. It must have perfect precision in representing microseconds, forever
3. It must make an exact round-trip for any possible input
4. It must let users use whatever epoch they want
These ideals cannot all be met simultaneously and perfectly. The correct thing
to do as an engineer is to choose a practical compromise and document the
decision.
The compromise that almost everyone chooses (because it is useful, convenient,
has microsecond precision at least until the year 2100, and millisecond
precision is frequently sufficient) is to use a floating-point number with an
epoch of 1970-01-01. Floating-point seconds can be easily subtracted, added,
serialized, and deserialized, and are a primitive data type in nearly every
language and database. They are unmatched in ease of use. So everyone wastes
time searching for the answer and figuring out how to write:
import calendar
calendar.timegm(dt.utctimetuple()) + dt.microsecond * 1e-6
We should use this as the definition of datetime.utctotimestamp(), document its
limitations, and be done with it.
Instead, this essential and useful method has now been held up for almost three
YEARS by an inability to accept a simple engineering decision. Unbelievable.
----------
nosy: +ping
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
