Marc-Andre Lemburg <m...@egenix.com> added the comment: Alexander Belopolsky wrote: > > 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."
mxDateTime needs those two methods, since it doesn't natively use timezones. The .ticks() method is used for local time values, .gmticks() for UTC ones; that's why there are two methods. The .gmticks() method is always used when storing UTC values in mxDateTime instances, which actually is the preferred way of storing data in databases. Google Code doesn't really count much, since it only scans a limited number of OSS code bases. Most of our users are commercial users who use the tools in-house. Note that implementing .gmticks() is fairly easy on POSIX conform systems. On most others, timegm() can be used. If that doesn't exist, things get tricky, but that case should be rare nowadays. >> 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. Note that he was referring to the .ticks() method, not the .gmticks() method. The patch doesn't say which version of mxDateTime he was using. The bug mentioned in the changelog was fixed in 1998. It is possible, however, that the mktime() on his system was broken - which is why I added a test for it in mxDateTime. >> >> 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. The time module is our reference in this case and this tries hard to add fractions of a second to the value :-) Note that sub-second accuracy relies on a number of factors, the storage format most certainly is the least important aspect ;-) On many systems, you only get 1/100s accuracy, on others, the timer ticks in fixed increments, giving you even weirder sub-second values (e.g. time appears to stay constant between time.time() calls). OTOH, there's a new set of APIs for nano-second accuracy available now, which the datetime module objects cannot represent at all due to the integer-based storage format. BTW: The integer format was chose in order to keep the memory footprint of the objects low. >> 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. No chance :-) In practice, the time module gets used a lot for date/time storage or to quickly measure time deltas. Some people also prefer time module ticks due to their lower memory footprint, esp. when it comes to storing thousands of time values in time series. >> 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. I had a look at the last patch on this ticket. >> 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. True, so make that two issues ;-) ---------- _______________________________________ 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
