Message124231
| 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:32 | pitrou | set | recipients:
+ 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:30 | pitrou | link | issue2736 messages |
| 2010年12月17日 17:17:30 | pitrou | create |
|