[Datetime-SIG] Trivial vs easy: .utcoffset()

Tim Peters tim.peters at gmail.com
Sun Aug 30 08:33:14 CEST 2015


[Alex]
>> The reason I think Python API is superior is because with exception
>> of leap seconds, all transitions in Olson database are given in local
>> time in the raw files.

[Tim]
> Well, they don't have to be in the plain text data files, that's just
> the default.  And overwhelmingly most common.  There are also ways to
> say "but this time is in the zone's 'standard time` regardless of
> is_dst", and "but this time is in UTC". ...

Here's a list of all the string values appearing in Rule-line "AT"
columns, each followed by the number of times it appears.  The ones
ending with "s" mean "standard time, not wall-clock time", and the
ones ending with "u" mean "UTC, not wall-clock time".  All others are
the default wall-clock time (which can be spelled with an explicit "w"
suffix, but never is):

0        1
0:00   755
0:00s   74
0:01    12
1:00    61
1:00s   40
1:00u   14
2:00   389
2:00s  277
2:30     7
2:45s    9
3:00    51
3:00s    3
3:00u   16
3:30    26
4:00     4
4:00u   12
5:00     2
9:00     1
11:00    1
12:00    2
22:00    1
22:00s  10
23:00   41
23:00s 105
23:00u   7
23:30    1
23:30s   1
24:00   20

I was surprised to see often "s" gets used.  For example, quite often
in France rules before 1940 (in the "europe" file).

You can even ask me what the difference is between "0:00 tomorrow" and
"24:00 today" ;-)  There really is a reason for that.  Some crazy
scheme switching at the end of the last Thursday of some month.
zoneinfo has a way to spell, e.g., "the last Thursday of March", but
not a way to spell "the day after the last Thursday of March", and
"the day after the last Thursday of March" isn't always "the last
Friday of March".  So you spell the switch as "24:00 on the last
Thursday of March".

Why on Earth would anyone switch DST during the work week?  That one
is tougher.  If the rules are changed every year, people get annoyed.
But if you never change the rules, then eventually DST will switch
during some important stretch of the Islamic calendar (which is lunar,
not solar, and has years about 11 days shorter than solar years).  So
the scheme above was apparently calculated to ensure Egypt wouldn't
switch DST near the start of Ramadan for at least a decade.  But then
they'll have to change the rules.  But not really, because they
already changed them again ;-)  Note that it can't work to define DST
in regular rules related to the Islamic calendar instead, because "the
reason" for DST is to adjust to physical realities related to the
solar calendar.

Then again, looks like the Egyptians are catching on to that there's
no real "reason" to mess with DST at all:

http://www.timeanddate.com/news/time/egypt-cancels-dst-2015.html

What I remain unclear about is why anyone would imagine any of this is
Python's problem ;-)


More information about the Datetime-SIG mailing list