On Jun 04, 2012, at 03:45 PM, Alexander Belopolsky wrote:

>Did you review the long discussion under issue 2736?  Specifically, please
>note the part about mxDateTime, ticks() and gmticks().  I am -0 on adding
>ticks() and gmticks() and as far as I can tell no one has implemented these
>methods for datetime without introducing some subtle bugs.

I skimmed it, but I don't have time to read the whole bug.  I'll note that
I've recently had to convert a bunch of code from using mxDateTime to
datetime+time, for the only reason that we had to support Python 3 and mxDT
isn't yet ported.

>I also suspect that those who ask for a timestamp() method expect that it
>will do more than
>
>EPOCH = datetime(1970, 1, 1)
>def timestamp(t):
>      return (t - EPOCH).total_seconds()

Not really.

>For example, account for leap seconds or magically guess the DST offset.  If
>we introduce a method that implements the code above, we have to prepare to
>explain why it does not do those things.

That's fine, explain away!

>If instead we introduce a shortcut for time.mktime(t.timetuple()), we will
>have to deal with the fact that mktime() behaves differently on different
>systems.

Not really.  If developers even care, they will know that the epoch is
different for different systems.  We don't have to deal with it, we just have
to mention it.  Let them use more verbose "correct" code if they care.

Seriously, we should not over-engineer this.  It's purely a more discoverable
convenience and I think implementing the moral equivalent to
time.mktime(t.timetuple()) is exactly the right thing to do.