On Fri, Dec 17, 2010 at 2:35 PM, Antoine Pitrou <report@bugs.python.org> wrote:
..
> I don't think the "time" module can be named "higher level", and it
> still handles such timestamps.
>
>> 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.
>
> Sigh.
> Again: it's so obvious that you're the only one who seems to easily come
> up with those solutions. How many times does it have to be repeated?
>

Remember, most of the code is written once, but read and edited many
times.  Show me one person who will have trouble understanding what
datetime(1970, 1, 1) + timedelta(seconds=s) means and show me another
who can understand datetime.utcfromtimestamp(s) without reading the
manual.

>> Compared to
>> this, "utcfromtimestamp" is a monstrosity that suggests that something
>> non-trivial, such as UTC leap seconds is been taken care of.
>
> I don't see anything suggesting it is a monstrosity. The name is
> grammatically bizarre, but that's all.
>

Yes, UTC not being a proper acronym in any human language is one
problem, Python datetime not being able to represent some valid UTC
times is another.

That's correct, but most users expect their timestamps to be the same
when saved on one system and read on another.  Granted, most users
expect the same from their floats as well, but this can only be solved
by education.   Calendaric calculations are complex enough that we
don't want to expose users to floating point gotchas at the same time.

>> Note that when timedelta.total_seconds() was first committed, it
>> contained a numerical bug.  See issue8644.
>
> So? What is your point?
>

I thought the point was obvious: conversion between time values and
float is non-trivial and error prone.  Users should not be encouraged
to casually convert (seconds, microseconds) tuples to floats.  If they
do, chances are they will do it differently in different parts of the
program.

>> 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.
>
> IMO, the solution would have the datetime object carry the offset from
> UTC with it, rather than try to be smart and compute it dynamically.
>

Ditto.  This is exactly what issue9527 is attempting to achieve.