On Aug 29, 2015, at 2:50 PM, Tim Peters <tim.peters@gmail.com> wrote:
So how can .utcoffset() be computed efficiently in a zoneinfo world using "hybrid" tzinfo classes (tzinfos that are smart enough to figure out the appropriate offset all on their own)?
As I am learning more about Olson/IANA database, I am more and more convinced that Python approach is better than that of UNIX. The Python approach is to provide effectively local to UTC mapping via utcoffset() while UNIX approach is to provide UTC to local mapping via the localtime() function. Python then supplies fromutc() which is real simple in regular cases and I think implementable in a general case while UNIX supplies its mktime which is a poke six times and hope it is enough mess. 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. The raw files then get "compiled" so that localtime() can be implemented efficiently and Olson never supplies his own mktime as far as I can tell. A familiar example where DST rules are simpler when formulated in local time are the US rules. In local time, all three (or four?) US zones have exactly the same rule - fall-back at 2am on first Sunday in November and spring-forward at the 2am on the second Sunday in March. Expressed in UTC, the transitions will be all at a different hour and may not even happen on the same day. I think the future of TZ support in Python is to come up with some automatic way to translate from raw Olson files to utcoffset()/dst()/tzname() implementations and invent some clever fromutc() algorithm that will correctly "invert" y = x - x.utcoffset() in all cases. For the later task, I have a solution in my prototype branch, but it requires up to six calls to utcoffset() which may indeed be the best on can do and it is not a coincidence that the number of calls in the worst case is the same as the number of pokes in mktime.