[tz] Irish Standard Time vs Irish Summer Time

[Deborah Goldsmith]

Hi,

It turns out that currently-shipping versions of ICU cannot deal with negative DST offsets; they will refuse to accept the data (illegal argument error). It’s a relatively simple fix, but changing this requires updating ICU, and rolling out the new version to the OS platforms that use it. That is a process that will probably require the better part of a year. As some have observed, Apple provides TZ database updates via a mechanism separate from the usual software release cycle. Such updates of course need to work with the version of ICU installed on customer’s devices.

Also, this change requires multiple data updates to Unicode’s Common Locale Data Repository, to align the localized names for Europe/Dublin (for summer and winter) with the new approach.

Would it be possible to roll this change out and plan to reintroduce it in the future, along with the changes needed in ICU and CLDR? (As well as a plan to deploy the updated ICU/CLDR to the field). I would also be OK with just backing it out period, but if we’re going to keep this change we need time for ICU and CLDR to adjust.

Meanwhile, clients of ICU are going to have to back this change out manually.

Thanks,
Debbie

> On Dec 9, 2017, at 11:11 AM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> 
> 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/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.
>