FWIW CLDR uses LOCODE for tzids in locale ids, such as en-u-tz-uslax for America/Los_Angeles • http://www.unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#Time_Zone_Ident... • http://www.unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#UnicodeTimezone... • http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/timezone.xml This is a registry and not an algorithm, so CLDR is responsible for its stability, as the ietf bcp47 -u- extension owner. On 2/10/17 8:31 AM, J Andrew Lipscomb wrote:
Hmm... are the coordinates shown in the zone.tab file stable enough to use as IDs? If so, then a geohash of the relevant point would be a reasonable choice that would fit in the 15 future bytes. Suitable schemes that come to mind are Geohash-36, a base-64 variant of the base-32 geohash.org scheme, or (if we wish to be a bit less obfuscatory) Maidenhead locators. And some other provisions for non-geographic zones.
More detailed analysis to follow when I'm at my full-powered computer.
Envoyé de mon iPhone