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/