On Fri, Dec 17, 2010 at 12:17 PM, Antoine Pitrou <report@bugs.python.org> wrote:
..
>> 1. Different application may need different epoch and retained
>> precision depends on the choice of the epoch.
>
> But then why does fromtimestamp() exist?

A better question is why datetime.utcfromtimestamp(s) exists given
that it is actually longer than equivalent EPOCH + timedelta(0, s)?  I
am not responsible for either of these methods, but at least
datetime.fromtimestamp(s, tz) is well defined for any timezone and
timestamp unlike its inverse.

> And returning a (seconds, microseconds) tuple does retain the precision.
>

It does, but it does not help much those who want a float - they would
still need another line of code.  Note that with divmod(timedelta,
timedelta), you can now easily extract   (seconds, microseconds)  or
any other tuple like (weeks, days, seconds. microseconds) from
timedelta objects.  See msg75904 above.

>> 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?
>

Well, no one has come up with the code that does work so far.  Note
that timetuple path does not work either because it does not fill
tm_isdst correctly.  The only solution I can think of for having
proper inverse to fromtimestamp() is to add isdst to datetime objects.
 This would allow correct round-tripping between datetime and
timetuple and datetime and timestamp.

>> 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?

Because in certain timezones fromtimestamp() can return the same
datetime value for different timestamps and some datetime values do
not have a corresponding timestamp.  I have not seen a working
proposal on how to handle these issues yet.  You are asking to provide
an inverse to an existing function simply because the function exists.
 But the function in question is not invertible.