Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
On Fri, Dec 17, 2010 at 1:17 PM, Antoine Pitrou <rep...@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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
