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 lemburg
Recipients Jay.Taylor, Neil Muller, amaury.forgeotdarc, andersjm, belopolsky, catlee, davidfraser, erik.stephens, guettli, hodgestar, jribbens, lemburg, mark.dickinson, ping, pitrou, r.david.murray, steve.roberts, tim.peters, tomster, vivanov, vstinner, werneck
Date 2011-04-05.09:50:43
SpamBayes Score 1.9295204e-10
Marked as misclassified No
Message-id <4D9AE5E0.8060904@egenix.com>
In-reply-to <1301993176.2709.0.camel@marge>
Content
STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> Marc, could you maybe write a new patching taking care of the DST and
> maybe also the timezone? It looks like you have a long experience in
> timestamps :-)

Sorry, but no. I'm not really a fan of the datetime module and
try to stay away from it whenever I can :-)

Note that dealing with DST in timezones other than the local time
zone, is bound to go wrong without direct access to the tz library.
The C lib doesn't provide any good way to access timezone
information other than the local timezone or UTC.

When dealing with date/time values, it is usually best to stay with
UTC and only transform those values into local times in user
interfaces on the front-end client.

Consequently, I'd suggest to only allow UTC and local timezone
conversions for the method in the datetime module.
History
Date User Action Args
2011-04-05 09:50:44lemburgsetrecipients: + lemburg, tim.peters, ping, jribbens, guettli, amaury.forgeotdarc, mark.dickinson, davidfraser, belopolsky, pitrou, andersjm, catlee, vstinner, tomster, werneck, hodgestar, Neil Muller, erik.stephens, steve.roberts, r.david.murray, vivanov, Jay.Taylor
2011-04-05 09:50:43lemburglinkissue2736 messages
2011-04-05 09:50:43lemburgcreate