Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Tue, Apr 5, 2011 at 4:33 AM, Marc-Andre Lemburg <rep...@bugs.python.org> wrote: .. > mxDateTime, which in large parts inspired the Python datetime module, > has had a .ticks() method (for local time) and a .gmticks() method > (for UTC) for more than a decade now Yes, mxDateTime's gmticks()/ticks() pair of functions present a much more mature design than anything that has been proposed here. It is telling, however, that no one has mentioned mxDateTime's gmticks() on this issue in four years. On a duplicate issue 1673409, Marc did bring it up, but as far as I can tell, no one responded. See msg75411. Google code search, http://www.google.com/codesearch?hl=en&sa=N&q=gmticks+lang:python returns only 13 hits for "gmticks". In several instances, the resulting float is immediately converted to int, in other instances "gmticks" is mentioned in comments and the code works around its bugs. I would not use Google Code search as an ultimate arbiter on the popularity of a feature, so I would really like to hear from the proponents about real life uses of gmticks() or any other examples where a similar method "has been reimplemented over and over again." > so far, I haven't seen a single complaint about any of the issues raised in > this discussion. Well, search for gmticks does not return too many hits outside of mxDateTime code and manuals, but I had no trouble finding this: """ okay, all the MySQLdb dataobject tick-based time handling methods are broken in various ways -- reconstruct GMT ticks from time module's mktime... """ http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=656863 Follow the link for some more colorful language describing developer's experience with the feature. Note that it is likely that the bug MySQLdb developer complained about was fixed in mxDateTime at some point, <http://www.egenix.com/www2002/python/mxDateTime-History.html>, but this shows that implementing gmticks() correctly is not as trivial as those who never tried might think. > > The methods naturally return the Unix ticks value as float, > since that's what the time module uses as basis Which in turn is a mistake IMO. Note that POSIX does not use float timestamps for a reason. > and the whole purpose > of those methods is to make interaction with the time module easy > and straight-forward. This is not the goal that I would support. I would rather see code that uses datetime module not require time module methods at all. > Victor's patch could easily be updated to return floats as well, > to make it compatible with the time module. > Victor reported implementing two methods, one to return a float and another to return a tuple. See msg124259. I am not sure I've seen that code. > There's only one catch that Victor's patch doesn't include ... No, it is not about "only one catch". Victor's patch is simply wrong. For an aware datetime instance it extracts DST flag from tzinfo, but ignores the offset. ---------- _______________________________________ 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