Irish Standard Time vs Irish Summer Time
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
Neil Fuller via tz said:
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."
Well, that's broken for a start: Lord Howe Island. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 01/19/2018 03:13 AM, Neil Fuller via tz wrote:
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.
Yes, this would be one route forward, after 2018c comes out. (2018c will roll back the Irish changes temporarily.) That is, the idea would be to have a good way to generate a variant of the zi files that does not use negative DST offsets. Android currently doesn't support time stamps after 2038, right? So another approach would be a hack to add a table that works for current Android while still matching the desired behavior, by listing explicit transitions for each year through 2037. Something like the attached, say. (I have not tested or installed this patch and it won't be in 2018c; I'm floating it here just as an idea.) The advantage of this latter approach is that Android would agree with post-2018c tzdb behavior (including tm_isdst flags) for all time stamps that Android currently supports. PS. Thanks for the details about some of the problems on the Android side; I now understand a bit better what you're up against.
On 2018-01-19 17:53, Paul Eggert wrote:
Android currently doesn't support time stamps after 2038, right? So another approach would be a hack to add a table that works for current Android while still matching the desired behavior, by listing explicit transitions for each year through 2037. Something like the attached, say. (I have not tested or installed this patch and it won't be in 2018c; I'm floating it here just as an idea.) The advantage of this latter approach is that Android would agree with post-2018c tzdb behavior (including tm_isdst flags) for all time stamps that Android currently supports.
A lot of the distros, their various libraries, and date/time utilities that support localization on ARM and other mobile, IoT, and other consumer embedded platforms that are updated regularly (e.g. STBs) still run signed 32 bit time_t systems. Some of the 32 bit kernels, libraries, and packages now support 64 bit time_t and are adding warnings when 32 bit time_t is configured/built. That means about 1.5G Android devices and about .5G Apple devices based on shipment volumes and supported update lifetimes. On the Linux side, 15M Raspberry Pis may be as many as all the other 32 bit Unix systems deployed that support localization and are still updateable. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Android currently doesn't support time stamps after 2038, right? So another approach would be a hack to add a table that works for current Android while still matching the desired behavior, by listing explicit transitions for each year through 2037. Something like the attached, say. (I have not tested or installed this patch and it won't be in 2018c; I'm floating it here just as an idea.) The advantage of this latter approach is that Android would agree with post-2018c tzdb behavior (including tm_isdst flags) for all time stamps that Android currently supports.
I don't think we'll need anything that special, TBH. What we mostly need is consistency across the various open source projects we pull in. Android (at my level, at least) is an interesting study in combining / integrating lots of OS code. For historic releases we definitely had a bug WRT to negative DST [1] which would force our hand for releasing historic updates (much like Yoshito mentioned for ICU). Future facing, we are heavily reliant on ICU for formatting / strings so we probably keep the Android data / code consistent with their handling of the negative DST issue. I can't do much more testing to flush out other bugs unless I fabricate or get my hands on an ICU update with negative DST data. My horizons generally extend as far as the Android platform APIs. Without making the changes and having a cycle of app compatibility testing I can't easily tell what assumptions apps developed for Android have made regarding the DST information we expose through our platform APIs. However, app developers can release new versions more readily than we can release platform versions. Those that are still actively supporting their software, that is. I've put some info at the end about 2038 handling on Android if you're interested. PS. Thanks for the details about some of the problems on the Android side;
I now understand a bit better what you're up against.
You're welcome. Thanks again, Neil. Regarding Android behavior for time stamps after 2038: that depends on what APIs we're talking about. On the Java language side, there is certainly java.text.format.Time which handles 2037 (and other things) quite badly [2]. Most of the issues are burned into the API so I deprecated it a few releases ago. Although Android currently doesn't load transition data outside of the 32-bit range in its java.util.TimeZone implementation it could be expanded (it just takes the 32-bit transitions from our tzdata file, which is based on the zic output, so wider ranges are available). The java.util.TimeZone *APIs* should be fine from a 64-bit time perspective (even if they're a bit lacking in other respects). java.time and Android's version of ICU should also be fine: I have complete faith in their authors to have got the APIs and implementations correct from a 2038 perspective. I'm not actually 100% sure what the native API situation is for calls like mktime / localtime for native apps. Android uses code closely derived from tzcode, but for historic / unclear reasons time_t was allowed to be architecture dependent so last time I looked it was a 32-bit signed integer on 32-bit devices. That should become less of an issue as 32-bit devices disappear over time but probably affects plenty out there today. I'm mostly Java focused so this is outside my normal area. Things may have changed. [1] https://android-review.googlesource.com/#/c/platform/libcore/+/594073/ [2] https://developer.android.com/reference/android/text/format/Time.html -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902
participants (4)
-
Brian Inglis -
Clive D.W. Feather -
Neil Fuller -
Paul Eggert