On Fri, Jun 8, 2012 at 11:06 PM, Guido van Rossum <guido at python.org> wrote:
> On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
..
>>>>> 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.
>
> So LocalTimezone (or any named timezone that uses DST) should not be
> used for this purpose.
..
> I'm still unsure what problem you're trying to solve.
The problem is: produce a timestamp (e.g. RFC 3339) complete with
timezone information corresponding to the current time or any other
unambiguously defined time. This is exactly what my proposed
datetime.localtime() function does.
> Can we just
> introduce LocalTimezone (or whatever name it should have) and let the
> issue rest?
No. LocalTimezone adresses a different problem and does not solve
this one. If you generate a timestamp using
datetime.now(LocalTimezone).strftime("... %z"), your timestamps will
be wrong for one hour every year. Some users may tolerate this, but
the problem is not hard to solve and I think datetime module should
offer one obvious and correct way to do it.
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