This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Alexander.Belopolsky, Neil Muller, amaury.forgeotdarc, andersjm, belopolsky, catlee, davidfraser, erik.stephens, guettli, hodgestar, jribbens, mark.dickinson, pitrou, r.david.murray, steve.roberts, tebeka, tim.peters, tomster, vivanov, vstinner, werneck
Date 2010-12-17.17:17:30
SpamBayes Score 1.4808749e-08
Marked as misclassified No
Message-id <1292606247.3672.6.camel@localhost.localdomain>
In-reply-to <AANLkTikTqMMturzPCaFPZ3Fj7odhSXdFAKPbRH0iLeXE@mail.gmail.com>
Content
> 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?
History
Date User Action Args
2010-12-17 17:17:32pitrousetrecipients: + pitrou, tim.peters, jribbens, guettli, amaury.forgeotdarc, tebeka, mark.dickinson, davidfraser, belopolsky, andersjm, catlee, vstinner, tomster, werneck, hodgestar, Neil Muller, erik.stephens, steve.roberts, r.david.murray, Alexander.Belopolsky, vivanov
2010-12-17 17:17:30pitroulinkissue2736 messages
2010-12-17 17:17:30pitroucreate