On Mon, Jun 11, 2012 at 6:33 AM, Alexander Belopolsky
<alexander.belopol...@gmail.com> wrote:
> On Fri, Jun 8, 2012 at 11:06 PM, Guido van Rossum <gu...@python.org> wrote:
>> On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky
>> <alexander.belopol...@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.
Maybe the problem here is the *input*? It should be a POSIX timestamp,
not a datetime object.
Another approach might be to tweak the existing timetuple() API to
properly compute the is_dst flag? It currently always seems to return
-1 for that flag.
>> 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.
Ok, I trust that LocalTimezone doesn't solve your problem. Separately,
then, I still think we should have it in the stdlib, since it probably
covers the most use cases besides the utc we already have.
PS. TBH I don't care for the idea that we should try to hide the time
module and consider it a low-level implementation detail for the shiny
high-level datetime module. The simply serve different purposes. Users
should be required to understand POSIX timestamps and the importance
of UTC before they try to work with multiple timezones. And they
should store timestamps as POSIX timestamps, not as datetime objects
with an (implicit or explicit) UTC timezone.
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
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
