Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
On Fri, Dec 17, 2010 at 2:35 PM, Antoine Pitrou <rep...@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. ---------- _______________________________________ 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
