[tz] Irish Standard Time vs Irish Summer Time
howard.hinnant at gmail.com
Sat Dec 9 19:27:28 UTC 2017
On Dec 9, 2017, at 2:11 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> PS. Howard, that debugging assertion change <https://github.com/HowardHinnant/date/commit/1eeb4cd6522da8c05ccadf3868a076ba1856e61e> still looks dicey. It still forbids 3-hour DST, for example, even though POSIX TZ strings and the tzfile format both require support for 3-hour DST. POSIX requires support for UT offsets ranging from -24:00 to 24:59:59, so in theory the difference between DST and STD could be in the range -48:59:59 .. 48:59:59. tzdata supports offsets that are way wider, for what it's worth.
Agreed, there is some tricky logic in my local->utc lookup in detecting ambiguous and non-existent mappings. The logic could be made simpler, but at a performance cost. The job of that assert is to warn me if I need to double-check that logic. It did exactly what I needed it to this time: I widened the window on save, and reran the unit tests and confirmed that the only thing that changed was exactly what should have changed.
If save is allowed to vary from -inf to inf, I know my code will break.
I have different logic for handling posix-style timezones:
which will not break with an arbitrary save. However that code makes assumptions that are correct for posix, and incorrect for the IANA tzdb. For one, that the offset for in the prior and next transitions is trivially known without a lookup.
Maybe some day I will rewrite the logic for the IANA parser that I have more confidence in for a wider range of save. But for now that assert is my quality assurance.
I have no position on the IST/save issue. Yes, I think reports will come in. I don’t know how many or how serious they will be. I fixed my lib and am ready to go for this patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Message signed with OpenPGP
More information about the tz