On Fri, Dec 17, 2010 at 1:17 PM, Antoine Pitrou <report@bugs.python.org> 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,
timezone.utc).

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

and

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.