Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
On Fri, Dec 17, 2010 at 12:17 PM, Antoine Pitrou <rep...@bugs.python.org> wrote: .. >> 1. Different application may need different epoch and retained >> precision depends on the choice of the epoch. > > But then why does fromtimestamp() exist? A better question is why datetime.utcfromtimestamp(s) exists given that it is actually longer than equivalent EPOCH + timedelta(0, s)? I am not responsible for either of these methods, but at least datetime.fromtimestamp(s, tz) is well defined for any timezone and timestamp unlike its inverse. > 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. 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. See msg75904 above. >> 2. The code above works only on naive datetime objects assumed to be >> in UTC. > > So, if the "trivial" code doesn't work, you can't bring it up as an > argument against shipping this functionality, right? > Well, no one has come up with the code that does work so far. Note that timetuple path does not work either because it does not fill tm_isdst correctly. The only solution I can think of for having proper inverse to fromtimestamp() is to add isdst to datetime objects. This would allow correct round-tripping between datetime and timetuple and datetime and timestamp. >> 3. While it is not hard to extend the timestamp(t) code to cover aware >> datetime objects that use fixed offset tzinfo such as those with >> tzinfo set to a datetime.timezone instance, it is not well defined for >> the "smart" tzinfo implementations that do automatic DST adjustment. > > Still, fromtimestamp() exists and apparently fulfills people's > expectations. So why can't the same strategy be used for totimestamp() > as well? Because in certain timezones fromtimestamp() can return the same datetime value for different timestamps and some datetime values do not have a corresponding timestamp. I have not seen a working proposal on how to handle these issues yet. You are asking to provide an inverse to an existing function simply because the function exists. But the function in question is not invertible. ---------- _______________________________________ 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
