<div dir="ltr">Also see the previous discussion entitled &quot;Version in zoneinfo files?&quot; where the same suggestion was made.  The upshot was that we could append environ-like like strings ...<div><br></div><div><div>ZONE=America/Los_Angeles</div><div>VERSION=2015g</div><div><br></div><div>to the zoneinfo file (in some encoding, with a version bump), but nothing ever came of it.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 9, 2017 at 5:59 PM, Arthur David Olson <span dir="ltr">&lt;<a href="mailto:arthurdavidolson@gmail.com" target="_blank">arthurdavidolson@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>The tzid might be stored as a seemingly extraneous time zone abbreviation, presumably with magic characters (&quot;TZID&quot;?) prepended or appended for identification purposes. Other such information could be included using the same approach.<br><br></div>The fifteen &quot;reserved for future use&quot; bytes near the start of time zone binary files are too few for this purpose (take &quot;America/New_York&quot;--and cue Henny Youngman).<br><br></div>    @dashdashado<br></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 9, 2017 at 5:44 PM, Steven R. Loomis <span dir="ltr">&lt;<a href="mailto:srl@icu-project.org" target="_blank">srl@icu-project.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear TZ list,<br>
<br>
 I would like to propose that zic-compiled binaries (such as what shows<br>
up in /etc/zoneinfo) include the tzid (such as ‘America/New_York’).<br>
<br>
<br>
 I work on the ICU project (Unicode’s International Components for<br>
Unicode) and also CLDR (Unicode’s Common Locale Data Repository).  The<br>
ICU library consumes tz data, and uses the localized data from CLDR to<br>
(among other things) display translated time zone names of various<br>
sorts, and format different types of dates.<br>
<br>
 A perpetual problem is trying to detect the actual timezone of a<br>
platform. Ideally something like the TZ variable is set to a valid tz id<br>
such as America/New_York which we can use directly.  Otherwise, we try<br>
various approaches - including trying to resolve /etc/localtime’s<br>
symlink to see if it points to a file which appears to be in some sort<br>
of zic-compiled tree. This brings up bugs such as<br>
<a href="http://bugs.icu-project.org/trac/ticket/12770" rel="noreferrer" target="_blank">http://bugs.icu-project.org/tr<wbr>ac/ticket/12770</a> because various platforms<br>
use different paths as the targets of /etc/localtime - and some times,<br>
it&#39;s a doubly linked symlink.  In other cases, the file is just copied,<br>
and we have to trawl through /usr/share/zoneinfo looking for a binary<br>
file which matches.  There are other methods employed if these fail, but<br>
I think this will suffice for our purposes.<br>
<br>
 Even if ICU consumed the /etc/zoneinfo file directly, or was able to<br>
call the host to perform the calculations it needs, that would not<br>
suffice in terms of localized content.  As I think has been noted on<br>
this list before, it does not seem to be a goal of the tz database to<br>
collect these translated names, and tz-link.html does link to CLDR as<br>
one possible source of translations.<br>
<br>
 I think that this would benefit other users as well, by making zone<br>
files self identifiable. I think the JDK has to do similar analysis.<br>
Some JavaScript containers (Mozilla especially) now support IANA tz ids,<br>
such as in<br>
<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat#Parameters" rel="noreferrer" target="_blank">https://developer.mozilla.org/<wbr>en-US/docs/Web/JavaScript/Refe<wbr>rence/Global_Objects/DateTimeF<wbr>ormat#Parameters</a><br>
<br>
 Any thoughts or comments?<br>
<br>
 Thanks,<br>
   Steven<br></blockquote></div></div></div></div></blockquote></div></div></div></div>