This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients Jay.Taylor, Neil Muller, amaury.forgeotdarc, andersjm, belopolsky, catlee, davidfraser, erik.stephens, guettli, hodgestar, jribbens, lemburg, mark.dickinson, ping, pitrou, r.david.murray, steve.roberts, tim.peters, tomster, vivanov, vstinner, werneck
Date 2011-04-05.14:59:31
SpamBayes Score 1.6653345e-16
Marked as misclassified No
Message-id <BANLkTinhd2fqrojOS=+zzzX8iHrQ8UiTxQ@mail.gmail.com>
In-reply-to <4D9AD3C5.7010700@egenix.com>
Content
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."

> 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.
History
Date User Action Args
2011-04-05 14:59:33belopolskysetrecipients: + belopolsky, lemburg, tim.peters, ping, jribbens, guettli, amaury.forgeotdarc, mark.dickinson, davidfraser, pitrou, andersjm, catlee, vstinner, tomster, werneck, hodgestar, Neil Muller, erik.stephens, steve.roberts, r.david.murray, vivanov, Jay.Taylor
2011-04-05 14:59:32belopolskylinkissue2736 messages
2011-04-05 14:59:31belopolskycreate