[Datetime-SIG] PEP-431/495

Tim Peters tim.peters at gmail.com
Sun Aug 23 05:17:41 CEST 2015


[Tim]
>> Which is why arithmetic "belongs in" tzinfo too - how the local clock
>> acts is entirely about the timezone.

[Alexander]
> While this is a very logical conclusion, I find it challenging to explain
> why arithmetic selection flag "belongs" to tzinfo while the "local time
> disambiguation flag" "belongs" to the datetime instance.

Because "the rules" governing how the local clock works are defined by
the tzinfo, but what the local clock _displays_ is entirely in the
datetime.  And I'll now make that crystal clear ;-)

I hate digital clocks.  Because I grew up with analog clocks, and to
this very day when I see a digital clock I have to picture where "the
big hand" and "the little hand" are.  Otherwise I have no _real_ idea
what time it is.

So, on my monitor, I went to great lengths to find a non-cool analog
clock gadget.  Plain circular clock face, showing only 12 hours, white
background with black sans serif digits at each hour position, plain
black tick marks at each minute position. a plain black "hour hand"
and a longer black "minute hand", and no stinking useless "second
hand" ;-)

But there's _also_ an "AM" or "PM" near the 6, because while I hate
24-hour analog clocks too, the AM/PM distinction is important to me.

So what's wrong with this?  Not much.  It's confusing when - and only
when - I happen to be awake in the wee hours when daylight time ends.
The rules for when that happens are buried in the OS (my "tzinfo"
implementation), but to be  _maximally_ useful to me my clock gadget
(my "datetime") should _also_ display "fold=0" and "fold=1" across the
hours daylight time ends.

The lack of that indicator isn't a problem with my tzinfo, it's a
design flaw in my datetime instance.

And that's why fold belongs in the datetime.  Nobody realizes this
only because they've never had a clock that was designed by me ;-)


> It feels backwards: DST is the stuff about timezones while arithmetic
> is the stuff about datetime.  Yet, we have what we have.  In an
> alternative universe, maybe we could have a DateTime metaclass that
> would produce a separate datetime class for each timezone and then
> tzinfo would be a class variable rather than instance member.

General fact of life:  when someone takes a simple design with a few
warts that's nevertheless understandable with minor effort, and tries
to improve it by piling on layers of OO concepts, the result is
invariably something only the improver can make head or tail of.
Other than that, great idea ;-)


More information about the Datetime-SIG mailing list