[Python-Dev] Status on PEP-431 Timezones
tim.peters at gmail.com
Tue Jul 28 00:03:28 CEST 2015
[Tres Seaver <tseaver at palladion.com>]
> "Naive" alarm clocks (those which don't know from timezones) break human
> expectations twice a year, because their users have to be awake to fix
> them (or make the clock itself out-of-whack with real civil time for the
> hours between fixing and the actual transition). For confirmatoin, ask
> your local priest / pastor about the twice yearly mixups among
> congregants whose clocks don't self-adjust for the DST boundary: some
> show up late / early for church *every* time the local zone changes.
Sure. I don't see how this applies to Python's arithmetic, though.
For a start, you're talking about alarm clocks ;-) Note that "naive"
is a technical term in the datetime context, used all over the
datetime docs. However, I'm using "naive arithmetic" as a shorthand
for what would otherwise be a wall of text. That's my own usage; the
docs only apply "naive" and "aware" to date, time and datetime objects
(not to operations on such objects).
> I'd be in favor of dropping "days" from timedelta, myself, for just this
> reason: if "1 day" is the same for your usecase as "24 hours", then just
> do the math yourself.
timedelta objects only store days, seconds, and microseconds, which is
advertised. It would be bizarre not to allow to set them directly.
They're the only timedelta components for which instance attributes
exist. In the timedelta constructor, it's the seconds, milliseconds,
minutes, hours, and weeks arguments that exist solely for convenience.
You could "do the math yourself" for all those too - but why would you
want to make anyone do that for any of them? All the world's alarm
clocks would remain just as broken regardless ;-)
Even if days weren't a distinguished unit for timedelta, I'd still
much rather write, e.g.,
timedelta(hours=5*24 + 3)
etc. The intent of the first spelling is obvious at a glance.
More information about the Python-Dev