[tz] Irish Standard Time vs Irish Summer Time

[Neil Fuller]

Just to weigh in from an Android OS perspective: the Europe/Dublin DST
convention change is also problematic for the Android platform.

Most of what I would want to say has been said. Like many, I missed the
discussion in December about this change and I'm not sure I would have
grasped the full impact if I had.

I monitor the announcements list so it would have been most useful to me if
this change had been flagged ahead of time there. I started looking at
2018a when I saw discussion internally to Google and I was surprised I
hadn't seen an official announcement.

It might help to understand the impact of this change and the indirect
influence and interactions that the tzdata has in Android so I've included
some information below on my ongoing assessment as an FYI. The NITZ
standard[1] is probably the worst interaction I've seen so far.

In the meantime Android will probably have to take the same approach that
ICU has and patch the IANA data, or wait for 2018c to hopefully reverse the
convention back to what it was before.

As always, thanks to all of you for keeping the world turning!

Neil.

-------------

The latest Android code is downstream from both OpenJDK and ICU, with some
of it's own time zone code on the side. There is a custom implementation of
classes like java.util.TimeZone, but also code for time zone detection used
in smartphone devices.

Android will be exposed to any problems that the ICU/OpenJDK maintainers
mentioned, plus any in other OS libraries used that I haven't looked at yet.

Android uses tzdata in some places for transition calculations, but refers
to ICU for things like names. There may be other interactions. If the
tzdata had one interpretation, and ICU had another, Android's formatting
code might return (for example) Irish Standard Time in Winter.

I found a long-standing bug in the Android java.util.TimeZone code that
forces the DST adjustment to always be >= 0 and another elsewhere that
(obviously incorrectly) assumes DST always means +1 hour.

The time zone detection code on Android can use the time zone offset data
it has available on device and compare it against information sent by the
carrier via NITZ[1] to see if it can identify the user's time zone.

The NITZ documentation says:

"When the LTZ is compensated for DST (summertime), the serving PLMN shall
provide a DST parameter to indicate this. The adjustment for DST can be +1h
or +2h."

I'm looking into whether carriers / networks in Ireland have made the same
interpretation as the new IANA data. I suspect their hands are tied by the
NITZ standard which would probably prevent them passing a negative number.
There's probably a feedback loop here between the NITZ standard, what
carriers will send and what devices can accept that might take a while to
stabilize on any new convention, if it happens at all.

>From a support perspective, Android has three cohorts to deal with:

1) Devices running older versions of Android for which OEMs are still
providing over-the-air (OTA) system image updates. These can potentially
take code patches to correct issues.

2) Devices running older versions of Android that have the ability to
receive time zone rules data updates but not code.

3) Latest code under development for future Android releases.

If the Europe/Dublin change "sticks" in tzdata, the likely course for
supporting existing devices would be to patch the Android tzdata and
pretend the Europe/Dublin shift hasn't happened. Future devices could
potentially support negative DST adjustments if all the problems are caught
in advance.

[1] https://en.wikipedia.org/wiki/NITZ , see reference 1 for the standard I
quoted

-- 
Google UK Limited

Registered Office: 6 Pancras Square, London, N1C 4AG
Registered in England Number: 3977902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180119/367d4466/attachment-0001.html>