Message153928
| Author |
ncoghlan |
| Recipients |
Neil Muller, amaury.forgeotdarc, andersjm, belopolsky, catlee, davidfraser, eric.araujo, erik.stephens, guettli, hodgestar, jamesh, jribbens, loewis, mark.dickinson, ncoghlan, pboddie, pitrou, r.david.murray, rhettinger, steve.roberts, techtonik, tim.peters, tomster, vstinner, werneck |
| Date |
2012年02月22日.04:35:55 |
| SpamBayes Score |
3.2377215e-05 |
| Marked as misclassified |
No |
| Message-id |
<1329885363.04.0.682987816188.issue9527@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
One important thing to remember is that once a time is in the past, whether or not DST was in effect for that time *is never going to change*. That means converting a DST aware timezone to a fixed offset timezone will work just fine for historical times.
It's mainly applications that need to handle times in the *future* (where the DST dates are still subject to change) that have to be aware of the problems when trying to handle DST with fixed offset timezone objects.
I think it's sufficient if the documentation pushes developers of such applications towards modules like pytz and dateutil to get access to variable offset tzinfo implementations. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年02月22日 04:36:03 | ncoghlan | set | recipients:
+ ncoghlan, tim.peters, loewis, jribbens, rhettinger, pboddie, jamesh, guettli, amaury.forgeotdarc, mark.dickinson, davidfraser, belopolsky, pitrou, andersjm, catlee, vstinner, techtonik, tomster, werneck, hodgestar, Neil Muller, eric.araujo, erik.stephens, steve.roberts, r.david.murray |
| 2012年02月22日 04:36:03 | ncoghlan | set | messageid: <1329885363.04.0.682987816188.issue9527@psf.upfronthosting.co.za> |
| 2012年02月22日 04:35:56 | ncoghlan | link | issue9527 messages |
| 2012年02月22日 04:35:55 | ncoghlan | create |
|