Marc-Andre Lemburg <m...@egenix.com> added the comment: Just to add another data point to this discussion:
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 and so far, I haven't seen a single complaint about any of the issues raised in this discussion. The methods naturally return the Unix ticks value as float, since that's what the time module uses as basis and the whole purpose of those methods is to make interaction with the time module easy and straight-forward. Likewise, the epoch is also the same as the time module's one. Victor's patch could easily be updated to return floats as well, to make it compatible with the time module. There's only one catch that Victor's patch doesn't include: mktime() doesn't always work with DST set to anything but -1. mxDateTime checks the API at module load time and then determines whether it can be used with a DST setting or not (see the mxDateTime code for details). Not sure whether today's mktime() implementations still have any issues with this, but it's better to double-check than to get wrong results. http://www.egenix.com/products/python/mxBase/mxDateTime/ ---------- nosy: +lemburg _______________________________________ 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