[Python-Dev] TZ-aware local time

[Guido van Rossum]

On Tue, Jun 5, 2012 at 8:41 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Wed, Jun 6, 2012 at 1:14 PM, Guido van Rossum <guido at python.org> wrote:
>> You can try to enforce this, but users will ignore it, and happily
>> represent local time as UTC. I've seen people do this with POSIX
>> timestamps too -- use the UTC conversions between timestamps and time
>> tuples, and yet use time tuples to represent local time (the
>> timestamps are stored because integers are easier to store). And yes
>> they get in horrible trouble around DST and they don't understand why.
>> But they still do it.
>>
>> I think it's better to give users the rope they want than to try and
>> prevent them from hanging themselves, since otherwise they'll just use
>> the power cords as ropes and electrocute themselves.
>
> Agreed, I'm just asking that the particular brand of rope be the
> assumption that naive timezones are implicitly UTC and allowing
> transparent interoperation according to that assumption. If someone is
> just using them to represent local time, and only have to deal with
> local time in one location, then they'll still mostly be fine (setting
> aside DST problems).
>
> If naive times and tz-aware times can natively interoperate, then it
> provides a path towards making more of the stdlib tz-aware by default
> (such as returning objects with the timezone set to UTC).

I don't see how that follows. Forbidding the interaction between naive
and tz-aware datetime objects is a fundamental part of the design and
I won't be comfortable with dropping it without a whole lot more
discussion of the topic.

OTOH adding the "Local" timezone object to the stdlib (despite its
flaws) is a no-brainer for me, since it doesn't hurt those who don't
use it.

-- 
--Guido van Rossum (python.org/~guido)