On Tue, Jun 5, 2012 at 8:41 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Wed, Jun 6, 2012 at 1:14 PM, Guido van Rossum <gu...@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) _______________________________________________ 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
