Author ping
Recipients Neil Muller, amaury.forgeotdarc, andersjm, belopolsky, catlee, davidfraser, erik.stephens, guettli, hodgestar, jribbens, mark.dickinson, ping, pitrou, r.david.murray, steve.roberts, tim.peters, tomster, vivanov, vstinner, werneck
Date 2011-03-31.18:52:51
SpamBayes Score 1.38754e-07
Marked as misclassified No
Message-id <>
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.
Date User Action Args
2011-03-31 18:52:53pingsetrecipients: + ping, tim.peters, jribbens, guettli, amaury.forgeotdarc, mark.dickinson, davidfraser, belopolsky, pitrou, andersjm, catlee, vstinner, tomster, werneck, hodgestar, Neil Muller, erik.stephens, steve.roberts, r.david.murray, vivanov
2011-03-31 18:52:53pingsetmessageid: <>
2011-03-31 18:52:52pinglinkissue2736 messages
2011-03-31 18:52:51pingcreate