[Alex] >>> I will try to create a zoneinfo wrapping prototype as well, but I will >>> probably "cheat" and build it on top of pytz.
[Tim] >> It would be crazy not to ;-) Note that Stuart got to punt on "the >> hard part": .utcoffset(), since pytz only uses fixed-offset classes. >> For a prototype - and possibly forever after - I'd be inclined to >> create an exhaustive list of transition times in local time, parallel >> to the list of such times already there in UTC. [Alex] > Yes. The only complication is that you need four transition points instead > of two per year in a regular DST case: (1) start of gap; (2) end of gap; (3) > start of fold; and (4) end of fold. Once you know where you are with > respect to those points, figuring out utcoffset(), dst() and tzname() for > either value of fold is trivial. I wouldn't call those extras transitions - they're just warts hanging off of actual transitions. Earlier I showed Stuart how to determine everything about a possible fold from a UTC time using pytz's internal info, in PEP-431/495 Fri, 28 Aug 2015 01:01:06 -0500 He didn't reply that I saw, so it was either obvious or incomprehensible to him ;-) In any case, it just takes some very simple code once the transition record the UTC time belongs in is found. I'd be surprised if it weren't similarly easy to determine everything about a possible gap. At least in a zoneinfo wrapping, a hybrid tzinfo's .utcoffset() has to (at least internally) find "the transition record the UTC time belongs in" regardless. > ... > It's a shame though to work from a transitions in UTC list But that's what tzfiles store. It would be insane for a zoneinfo wrapping not to take advantage of that. For which reason, I do consider dateutil's zoneinfo wrapping to be insane ;-) (It inherits the default .fromutc()) Ah, BTW, I think dateutil's zoneinfo's wrapping also misunderstood some of what's actually in a tzfile. Specifically, a tzfile's " UTC/local indicators" and " standard/wall indicators" are 100% useless for anything we need, and shouldn't even be read from the file(*) (seek over 'em). > because most of DST rules are expressed in local times and then > laboriously converted into UTC. It's just a few lines of code in zoneinfo's zic.c. Nobody is doing it "by hand" there. > I think I should also implement the POSIX TZ spec tzinfo. For that you really should grab dateutil. It has a full implementation of POSIX TZ rules, as hybrid tzinfos; here from its docs: >>> tz1 = tzstr('EST+05EDT,M4.1.0,M10.5.0') >>> tz2 = tzstr('AEST-10AEDT-11,M10.5.0,M3.5.0') >>> dt = datetime(2003, 5, 8, 2, 7, 36, tzinfo=tz1) >>> dt.strftime('%X %x %Z') '02:07:36 05/08/03 EDT' >>> dt.astimezone(tz2).strftime('%X %x %Z') '16:07:36 05/08/03 AEST' Of course this implementation is tied into dateutil's rich supply of "calendar operations" too. > This is where the advantage of the "as intended" approach will be obvious. ? "As intended" is all about (to me) using hybrid tzinfos. And those are far richer in tzfiles than from POSIX rules. The latter only present us with simplest-possible DST transitions; tzfiles present us with every absurd political manipulation yet inflicted on humankind ;-) ------- (*) Long boring story. Short course: those indicators are only needed, on some systems, if a POSIZ TZ rule specifies a zone offset but gives no rules at all for daylight transitions, _and_ the system has a "posixrules" tzfile. Then an insane scheme is used to make up daylight rules "as if" the source file from which the posixrules tzfile was created had been for a zone with the TZ-specified standard offset instead, and these absurd indicators are used to figure out whether the posixrules source file specified _its_ daylight rules using UTC or local times, and if the later case then whether using standard time or wall-clock time instead. It's completely nuts. -- https://mail.python.org/mailman/listinfo/python-list