[tz] Irish Standard Time vs Irish Summer Time

[Neil Fuller]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180122/19c58d6e/attachment-0001.html>