[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 ;-)