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