> 1. Different application may need different epoch and retained
> precision depends on the choice of the epoch.
But then why does fromtimestamp() exist?
And returning a (seconds, microseconds) tuple does retain the precision.
> 2. The code above works only on naive datetime objects assumed to be
> in UTC.
So, if the "trivial" code doesn't work, you can't bring it up as an
argument against shipping this functionality, right?
> 3. While it is not hard to extend the timestamp(t) code to cover aware
> datetime objects that use fixed offset tzinfo such as those with
> tzinfo set to a datetime.timezone instance, it is not well defined for
> the "smart" tzinfo implementations that do automatic DST adjustment.
Still, fromtimestamp() exists and apparently fulfills people's
expectations. So why can't the same strategy be used for totimestamp()
as well? |