> I wrote: > > > Alas datetime objects do not unambiguously identify a point in time. > > datetime objects are not timestamps: They represent the related but > > different concept of _local time_, which can be good for > presentation, > > but shouldn't be allowed anywhere near a persistent store. > GvR replied: > You misunderstand the datetime module! You can have a datetime object > whose timezone is UTC; or you can have a convention in your API that > datetime objects without timezone represent UTC.
I can do a lot of things in my own code, and I'm sure the datetime module provides tools that I can build on to do so, but that doesn't help in interfacing with other people's code -- such as the standard library. Try saving a pickle of datetime.now() and reading it on a computer set to a different time zone. The repr will then show the local time on the _originating_ computer, and figuring out the absolute time this corresponds to requires knowledge of time zone and DST settings on the originating computer. How about datetime.utcnow(), then? Just use UTC for datetime timestamps? But that goes against the grain of the datetime module: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime, time >>> datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.now() datetime.timedelta(0) >>> datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.utcnow() datetime.timedelta(0, 7200) It seems when I subtract the present time from the present time, there's a two hour difference. - Anders _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
