On 12/09/2017 06:00 AM, Mark Davis ☕️ wrote:
I am worried that a significant number of implementations may keel over if handed negative offsets.
So far we've found one specific trivial formatting glitch <https://mm.icann.org/pipermail/tz/2017-December/025696.html>, and one library <https://mm.icann.org/pipermail/tz/2017-December/025694.html> with a debugging assertion about DST offsets that was incorrect. If these examples are typical, then there is little to worry about; if more-significant problems show up, then the tzdata change may need to be reverted. There is a tension here between trying to support daylight-saving time practice, and trying to keep our code and machines running. Although we want both objectives, they sometimes compete. Here the gain is small (supporting IST as it was intended). If the cost is trivial (a few formatting glitches or debug runs fail until software is corrected) then the gain is worth the cost; if the cost is large (some user programs crash in typical operation) then it's not. So far we've seen only trivial costs. PS. Howard, that debugging assertion change <https://github.com/HowardHinnant/date/commit/1eeb4cd6522da8c05ccadf3868a076b...> 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.