Author Alexander.Belopolsky
Recipients Alexander.Belopolsky, Neil Muller, amaury.forgeotdarc, andersjm, belopolsky, catlee, davidfraser, erik.stephens, guettli, hodgestar, jribbens, mark.dickinson, pitrou, r.david.murray, steve.roberts, tebeka, tim.peters, tomster, vivanov, vstinner, werneck
Date 2010-12-17.18:57:15
SpamBayes Score 0.0
Marked as misclassified No
Message-id <>
In-reply-to <1292609857.3672.49.camel@localhost.localdomain>
On Fri, Dec 17, 2010 at 1:17 PM, Antoine Pitrou <> wrote:
>> A better question is why datetime.utcfromtimestamp(s) exists given
>> that it is actually longer than equivalent EPOCH + timedelta(0, s)?
> ??? EPOCH is not even a constant in the datetime module.
No, and it does not belong there.  A higher level library that uses
seconds since epoch for interchange may define it (and make a decision
whether it should be a naive datetime(1970, 1, 1) or datetime(1970, 1,
1, tzinfo=timezone.utc)).

> And regardless, the point is *not* the number of characters typed, but
> how easy it is to come up with the solution. Calling the appropriate
> (and appropriately-named) method is much easier than coming up with the
> right datetime arithmetic incantation. It's Python, not Perl. "There
> should be one obvious way to do it".

I don't see anything obvious about the choice between
utcfromtimestamp(s), fromtimestamp(s) and utcfromtimestamp(s,

datetime(1970, 1, 1) + timedelta(seconds=s)

is obvious, self-contained,  short and does not require any knowledge
other than elementary school arithmetic to understand.  Compared to
this, "utcfromtimestamp" is a monstrosity that suggests that something
non-trivial, such as UTC leap seconds is been taken care of.

>> > And returning a (seconds, microseconds) tuple does retain the precision.
>> >
>> It does, but it does not help much those who want a float - they would
>> still need another line of code.
> Yes, but a very obvious one at least.

Let's see:

def floattimestamp(t):
      s, us = t.totimestamp()
      return s + us * 1e-6


def floattimestamp(t):
      s, us = t.totimestamp()
      return s + us / 1000000

which one is *obviously* correct?  Are they *obviously* equivalent?

Note that when timedelta.total_seconds() was first committed, it
contained a numerical bug.  See issue8644.

>> Note that with divmod(timedelta,
>> timedelta), you can now easily extract   (seconds, microseconds)  or
>> any other tuple like (weeks, days, seconds. microseconds) from
>> timedelta objects.
> Do you think many users even think of calling divmod() timedelta
> objects? I don't, personally.
> You apparently hold the opinion that the datetime module should be
> reserved for experts in arithmetic over dates, times and timedeltas. But
> it's not. It's the Python stdlib and it should provide reasonably
> high-level tools to do the job.

Sure, but if the goal is to implement json serialization of datetime
objects, maybe stdlib should provide a high-level tool for *that* job?
  Using float representation of datetime is probably the worst option
for json: it is non-standard, may either loose information or
introduce spurious differences, and is not human-readable.

In any case, you ignore the hard question about totimestamp():
fromtimestamp() is not invertible in most real life timezones.  If you
have a solution that does not restrict totimestamp() to UTC, I would
like to hear it.  Otherwise, I don't see any problem with (t -
datetime(1970, 1, 1)).total_seconds() expression.  Maybe we can add
this recipe to utcfromtimestamp() documentation.
Date User Action Args
2010-12-17 18:57:18Alexander.Belopolskysetrecipients: + Alexander.Belopolsky, tim.peters, jribbens, guettli, amaury.forgeotdarc, tebeka, mark.dickinson, davidfraser, belopolsky, pitrou, andersjm, catlee, vstinner, tomster, werneck, hodgestar, Neil Muller, erik.stephens, steve.roberts, r.david.murray, vivanov
2010-12-17 18:57:15Alexander.Belopolskylinkissue2736 messages
2010-12-17 18:57:15Alexander.Belopolskycreate