On Tue, Jun 5, 2012 at 6:07 PM, Guido van Rossum <gu...@python.org> wrote: >> See http://bugs.python.org/issue9527 . >
With datetime.timestamp() method committed, I would like to get back to this issue. In some sense, an inverse of datetime.timestamp() is missing from the datetime module. Given a POSIX timestamp, I cannot get the local time as an aware datetime object. > Reading the requirements for a timezone implementation and the > time.localtime() function, it would seem that a timezone object > representing "local time" can certainly be constructed, as long as the > time module uses or emulates the Unix/C behavior. A tzinfo subclass emulating local time rules introduces the DST ambiguity to a problem that does not inherently suffer from it. See <http://bugs.python.org/issue9063>. A typical application is an e-mail agent that has to insert local time complete with UTC offset in the message header. The time.localtime() method will produce local time components together with the dst flag from which time.strftime() can produce RFC 3339 timestamp using "%z" directive. There is no ambiguity during DST transition. The only complication is that time component TZ components exhibit canceling discontinuities at those times. For example, >>> t = mktime((2010, 11, 7, 1, 0, 0, -1, -1, 0)) >>> for i in range(5): ... print(strftime("%T%z", localtime(t + i - 2))) ... 01:59:58-0400 01:59:59-0400 01:00:00-0500 01:00:01-0500 01:00:02-0500 As I explained at <http://bugs.python.org/msg109452>, it is not possible to reproduce this sequence using LocalTimezone. > I don't like that function. It returns two different timezone objects > depending on whether DST is in effect. Also it adds a new method to > the datetime class, which I think is unnecessary here. We can avoid introducing new methods. We can add aware= flag to datetime.now() and datetime.fromtimestamp(), but it may be better to introduce special values for existing tzinfo= argument instead. For example, we can allow passing an empty string in tzinfo to signify that a timezone instance should be generated filled with appropriate local offset. This choice may seem less of a hack if we introduce some simple TZ parsing and allow string values like "UTC-0500" as valid tzinfo specifications. _______________________________________________ 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
