Anthony Baxter wrote: > > >>> "M.-A. Lemburg" wrote > > I tried that in early version of mxDateTime -- it fails > > badly. I switched to the local time assumption very > > early in the development. > > If you must store stuff without timezones, _please_ don't use > localtime. localtime is a variable thing (think what happens > when daylight savings goes on and off). You probably didn't notice the "assumption" -- mxDateTime has a few APIs which make assumptions about the value stored in DateTime objects; however, you can just as well store UTC in them. In that case, the APIs making the local time assumption will produce wrong data of course. >>> from mx.DateTime import * >>> now() # local time <DateTime object for '2002-02-27 10:33:52.63' at 8199ec0> >>> now().gmtime() # in UTC <DateTime object for '2002-02-27 09:33:55.72' at 8196b38> In the end, it's better to leave the decision what to store in a DateTime object to the programmer. Timezones, DST and leap seconds sometimes have their application and sometimes just cause plain confusion. IMHO, the application should decide what to do about them and manage the data storage aspects of its decision. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4