Support for Etc/GMT -style zones ids with partial hours
Would there be any support in this community for adding new Etc/GMT[-+] zone identifiers but with partial hours? e.g. something like "Etc/GMT-5:30" These might introduce some technical challenges, but I can see a use which I will explain below. I haven't yet investigated the impact on Android (where I deal with much of the time zone work), but I thought I'd ask for thoughts before expending any effort prototyping. Thanks, Neil. ------------------ Motivating case: Taking Android as an example, the platform uses TZDB zone identifiers as the basis for most time zone support. Directly, via a tzif-based file (used for libc mktime/localtime / Android's custom implementation of java.util.TimeZone), and indirectly via ICU4C and ICU4J. In situations like we had this week with Palestine, i.e. less than one week's notice before a DST transition change, the usual advice for users affected is "Please manually select an alternative time zone that has the offset you need until you receive a software update". e.g. Microsoft Windows appears to do the same [1] Side note: There are related cases for devices that have fallen out of their OEM's support window and will never receive a TZDB update again. The utility of these devices can degrade over time as their version of TZDB slowly drifts from the user's reality. Users continuing to use these devices may no longer be able to use the identifier for their actual location and get the behavior they need. Instead, they have to select an alternative zone ID that has the offset they need. If they're not lucky, they may be forced to pick an alternative zone ID which has its own DST schedule which might not match their requirements for the full year. The Stock Android settings UI, starting with Android Pie (9.0), allows users to select from the fixed "Etc/GMT-5" style identifiers from TZDB in addition to the more regular "Europe/London"-style zone identifiers associated with geographical regions. The original use case for this was to allow pilots to select Etc/UTC, and we added support for selecting all the other fixed Etc/GMT[+-] zones at the same time. The current Etc/GMT[+-] zone identifiers in TZDB only cover whole hour offsets. There are various places that use 30 minute offsets, and a few that use 45/15 minute offsets [2]. For the cases where devices cannot receive rules updates (in time, or at all), it would be useful to have the full range of 30-minute fixed-offset possibilities for users to select from instead. I'm choosing to ignore the 15/45 minute ones right now as they appear much less common / useful. Because most of our infrastructure treats TZDB as "ground truth" it would be beneficial to get this support in TZDB rather than carrying local patches to each library. [1] https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/interi... - this example is for Fiji / 2020b [2] https://www.timeanddate.com/time/time-zones-interesting.html - zones with offsets other than integer hours -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902
On Wed 2020-10-21T18:12:13+0100 Neil Fuller via tz hath writ:
Would there be any support in this community for adding new Etc/GMT[-+] zone identifiers but with partial hours? e.g. something like "Etc/GMT-5:30"
If this happens then at the same time I would like to see the full-hour zones extended to support pre-1925 astronomical calendars which are still in use at observatories. In particular Etc/GMT+20 has been the basis of the calendar at Lick Observatory for 130+ years. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
On 10/21/20 10:12 AM, Neil Fuller via tz wrote:
The Stock Android settings UI, starting with Android Pie (9.0), allows users to select from the fixed "Etc/GMT-5" style identifiers from TZDB
How does that work at the user level? I have an Android 10 phone (build QQ1A.200105.032), and couldn't see these UI options under either "Settings>System>Date & time>Time zone" or "Clock>⋮>Settings>Home time zone" (these have different UIs).
The current Etc/GMT[+-] zone identifiers in TZDB only cover whole hour offsets. There are various places that use 30 minute offsets, and a few that use 45/15 minute offsets [2].
I suppose we could add IDs for non-hour offsets currently in use. I worry, though, that there will be more odd offsets outside the civil-aviation application area, such as the offsets that various astronomical observatories use (as Steve Allen mentioned). In GNU/Linux the way to solve this problem is to use a TZ setting like TZ='<+0545>-5:45' for Nepal (or TZ='NPT-5:45' for older POSIX). Does this work for Android? If so, I suggest going that way. If not, perhaps POSIX TZ support should be added to Android; that shouldn't be hard, and would improve functionality and compatibility in other areas too. If it couldn't be done for Android it could at least be done for the Clock app.
How does that work at the user level? I have an Android 10 phone (build QQ1A.200105.032), and couldn't see these UI options under either "Settings>System>Date & time>Time zone" or "Clock>⋮>Settings>Home time zone" (these have different UIs).
Partners are free to replace / modify settings up to a point, but even in the stock code the support for fixed offsets is *not* very obvious. This is partly by design as it's a niche use case. In the top right corner usually there's a menu button with a single item: "Select by UTC offset" which puts the settings picker into a different mode. It's the Settings that is considered part of the Android platform (where I work). The Clock app is an app that operates on many versions of Android and can be updated independently. As far as I know relies on the TZDB rules provided by the platform but it ships with a list of the more common zones, not a comprehensive list. In GNU/Linux the way to solve this problem is to use a TZ setting like
TZ='<+0545>-5:45' for Nepal (or TZ='NPT-5:45' for older POSIX). Does this work for Android? If so, I suggest going that way. If not, perhaps POSIX TZ support should be added to Android; that shouldn't be hard, and would improve functionality and compatibility in other areas too. If it couldn't be done for Android it could at least be done for the Clock app.
I know that wouldn't work today. I'm sorry to say it would also probably be quite a lot more work than adding new entries to TZDB. The odds of Android consistently supporting the newer POSIX free-form any time soon are probably low. I'll try to explain... In short, this is because Android uses a combination of various open source libraries. There are a lot of history / compatibility considerations. i.e. all the parts agree on what the TZDB identifiers mean, but probably not more than that. I've seen a few pieces of fallback logic that first try to treat a string as a TZDB identifier before falling back to other parsing (but which differ). There's the extra dimension that 3rd party apps may also be reading this information, and so existing apps and they libraries they use may break when confronted with something in the form '<+0545>-5:45' when they're expecting a TZDB identifier, or conform to an older POSIX spec. I know support for non-TZDB identifiers was explicitly removed before I started working on Android. For example [3]: * <p> On android M and above, it is an error to pass in a non-Olson timezone to this * function. Note that this is a bad idea on all Android releases because POSIX and * the {@code TimeZone} class have opposite interpretations of {@code '+'} and {@code '-'} * in the same non-Olson ID. To be honest, just adding new "Etc/GMT-5:30" identifiers could also cause problems (not just for Android), but it seems likely it could be made to work without too much effort on the Android side. Even if there was enthusiasm here, I would want to try it out and would need to consider the effect on older releases of Android in case the colon character broke something, or a widely used app out there would try to parse anything after "GMT" as an integer! Just for completeness: Android does not primarily use the TZ environment variable: components like our libc and managed code have been altered to refer to Android's system property libraries, which ensures that all long-running programs are informed via events (AKA Intents on Android) when the value changes. This ensures that the UI updates and that the various APIs we expose to apps return a consistent answer regardless of when the process started. This is similar to what happens when the user changes their preferred language settings. Neil. [3] https://android.googlesource.com/platform/frameworks/base/+/refs/heads/maste... On Wed, 21 Oct 2020 at 18:50, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 10/21/20 10:12 AM, Neil Fuller via tz wrote:
The Stock Android settings UI, starting with Android Pie (9.0), allows users to select from the fixed "Etc/GMT-5" style identifiers from TZDB
How does that work at the user level? I have an Android 10 phone (build QQ1A.200105.032), and couldn't see these UI options under either "Settings>System>Date & time>Time zone" or "Clock>⋮>Settings>Home time zone" (these have different UIs).
The current Etc/GMT[+-] zone identifiers in TZDB only cover whole hour offsets. There are various places that use 30 minute offsets, and a few that use 45/15 minute offsets [2].
I suppose we could add IDs for non-hour offsets currently in use. I worry, though, that there will be more odd offsets outside the civil-aviation application area, such as the offsets that various astronomical observatories use (as Steve Allen mentioned).
In GNU/Linux the way to solve this problem is to use a TZ setting like TZ='<+0545>-5:45' for Nepal (or TZ='NPT-5:45' for older POSIX). Does this work for Android? If so, I suggest going that way. If not, perhaps POSIX TZ support should be added to Android; that shouldn't be hard, and would improve functionality and compatibility in other areas too. If it couldn't be done for Android it could at least be done for the Clock app.
-- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902
On 10/21/20 11:45 AM, Neil Fuller wrote:
To be honest, just adding new "Etc/GMT-5:30" identifiers could also cause problems (not just for Android), but it seems likely it could be made to work without too much effort on the Android side. Even if there was enthusiasm here, I would want to try it out and would need to consider the effect on older releases of Android
One way to do that would be to add a file etc-rare that contains these less-commonly-used and/or problematic offsets. Something like the attached, say. You can try this out in your Android builds. Not sure whether it'd be worthwhile putting it into tzdb, as this sort of thing could be a neverending story and anyway it really should be done via a POSIX-style TZ support.
Thanks Paul. I wasn't aware of the extra astronomy cases before this thread, so also thanks Steve. This just goes to show there are various ways to interpret this and why it's right to consider alternatives. For example, I had assumed TZDB would want to add identifiers for *all* +-30 zones that _could_ exist and not just the ones that would be used today. That would be on the grounds that one part of my motivating example is about keeping the utility of old Android devices that no longer receive rule updates. For example, if a country decides to move to a xx:30 offset that hasn't previously existed (maybe like North Korea did?) then affected users would still have a TZDB identifier they could select. Waiting for a rules update to allow for new xx:30 identifiers would defeat the purpose. Additionally, because of the number of possible 15/45 zone identifiers, and the relatively sparsely populated areas that used them, I had assumed they weren't worth the effort / cost of adding them at all, i.e. adding all the possible xx:30 zones only carries a cost of ~24 new zone IDs, but "buys me" (today) parts of India/Australia/Canada/Sri Lanka/Iran/Myanmar, which is clearly a lot of people with old devices who might benefit. Adding the ~48 15/45 zone IDs would "only" buy me Nepal and Eucla today. So, it's much less easy to make a case for enlarging the identifier count for 15/45 by so many. Having so many GMT+- identifiers in total also has UI implications if we're just displaying a list of Etc/GMT[+-] like I think we do today. Clearly there are other ways to design an UI, especially if we could guarantee that *all* possible combinations of hours between -14 and +12 and minutes of 15/30/45 could be mapped to an Etc/GMT[+-] zone identifier in a straightforward way. Holding an additional file that I can patch into our generation process locally will certainly work. I'm assuming ICU wouldn't want to support non-standard identifiers "out of the box" without the nod from TZDB, so the downside is that it will mean patching both Android's ICU and "other" TZDB update processes, and possibly other metadata files for translations, etc. Avoiding this by changing TZDB directly instead was a low-priority goal of mine since holding patches means overhead each time we upgrade our version of ICU. We do have tests that confirm that ICU4x understands all the TZDB identifiers we support elsewhere, so at least we'd catch it if we accidentally lost a patch through an overzealous ICU upgrade. This certainly gives me food for thought and I appreciate the responses. I won't request anything further right now. I don't know when I'll get a chance to try out an Android patch, but if I find anything surprising that might benefit the wider community then I'll let you all know. Neil. On Thu, 22 Oct 2020 at 08:21, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 10/21/20 11:45 AM, Neil Fuller wrote:
To be honest, just adding new "Etc/GMT-5:30" identifiers could also cause problems (not just for Android), but it seems likely it could be made to work without too much effort on the Android side. Even if there was enthusiasm here, I would want to try it out and would need to consider the effect on older releases of Android
One way to do that would be to add a file etc-rare that contains these less-commonly-used and/or problematic offsets. Something like the attached, say. You can try this out in your Android builds. Not sure whether it'd be worthwhile putting it into tzdb, as this sort of thing could be a neverending story and anyway it really should be done via a POSIX-style TZ support.
-- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902
participants (3)
-
Neil Fuller -
Paul Eggert -
Steve Allen