Author pitrou
Recipients Alexander.Belopolsky, Neil Muller, amaury.forgeotdarc, andersjm, belopolsky, catlee, davidfraser, erik.stephens, guettli, hodgestar, jribbens, mark.dickinson, pitrou, r.david.murray, steve.roberts, tim.peters, tomster, vivanov, vstinner, werneck
Date 2010-12-17.19:35:42
SpamBayes Score 3.60822e-15
Marked as misclassified No
Message-id <1292614540.3672.82.camel@localhost.localdomain>
In-reply-to <AANLkTik8xGNzvgCR=xMb96QQF9Vb-ik-0FyGptNvw95r@mail.gmail.com>
Content
> > ??? EPOCH is not even a constant in the datetime module.
> >
> No, and it does not belong there.

And so what was your point exactly?

> A higher level library that uses
> seconds since epoch for interchange

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?

> 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.

> Let's see:
> [snip]
>
> which one is *obviously* correct?  Are they *obviously* equivalent?

Both are obviously correct for whatever the non-perverted user has in
mind. People in real life don't care whether they will retain
microsecond precision when carrying a floating point timestamp around.
For the simple reason that the data source itself will not have such
precision.

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

So? What is your point?

> 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.
History
Date User Action Args
2010-12-17 19:35:44pitrousetrecipients: + pitrou, tim.peters, jribbens, guettli, amaury.forgeotdarc, mark.dickinson, davidfraser, belopolsky, andersjm, catlee, vstinner, tomster, werneck, hodgestar, Neil Muller, erik.stephens, steve.roberts, r.david.murray, Alexander.Belopolsky, vivanov
2010-12-17 19:35:43pitroulinkissue2736 messages
2010-12-17 19:35:42pitroucreate