[issue2736] datetime needs an "epoch" method
report at bugs.python.org
Fri Dec 17 20:35:44 CET 2010
Antoine Pitrou <pitrou at free.fr> added the comment:
> > ??? 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.
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:
> 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
> 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.
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list