[tz] Support for Etc/GMT -style zones ids with partial hours
Neil Fuller
nfuller at google.com
Thu Oct 22 09:52:51 UTC 2020
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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20201022/94c45ea5/attachment.htm>
More information about the tz
mailing list