Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment:
> 
> On Tue, Apr 5, 2011 at 4:33 AM, Marc-Andre Lemburg
> <report@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 ;-)