[tz] tzid in zoneinfo?

[Bradley White]

Also see the previous discussion entitled "Version in zoneinfo files?"
where the same suggestion was made.  The upshot was that we could append
environ-like like strings ...

ZONE=America/Los_Angeles
VERSION=2015g

to the zoneinfo file (in some encoding, with a version bump), but nothing
ever came of it.

On Thu, Feb 9, 2017 at 5:59 PM, Arthur David Olson <
arthurdavidolson at gmail.com> wrote:

> The tzid might be stored as a seemingly extraneous time zone abbreviation,
> presumably with magic characters ("TZID"?) prepended or appended for
> identification purposes. Other such information could be included using the
> same approach.
>
> The fifteen "reserved for future use" bytes near the start of time zone
> binary files are too few for this purpose (take "America/New_York"--and cue
> Henny Youngman).
>
>     @dashdashado
>
> On Thu, Feb 9, 2017 at 5:44 PM, Steven R. Loomis <srl at icu-project.org>
> wrote:
>
>> Dear TZ list,
>>
>>  I would like to propose that zic-compiled binaries (such as what shows
>> up in /etc/zoneinfo) include the tzid (such as ‘America/New_York’).
>>
>>
>>  I work on the ICU project (Unicode’s International Components for
>> Unicode) and also CLDR (Unicode’s Common Locale Data Repository).  The
>> ICU library consumes tz data, and uses the localized data from CLDR to
>> (among other things) display translated time zone names of various
>> sorts, and format different types of dates.
>>
>>  A perpetual problem is trying to detect the actual timezone of a
>> platform. Ideally something like the TZ variable is set to a valid tz id
>> such as America/New_York which we can use directly.  Otherwise, we try
>> various approaches - including trying to resolve /etc/localtime’s
>> symlink to see if it points to a file which appears to be in some sort
>> of zic-compiled tree. This brings up bugs such as
>> http://bugs.icu-project.org/trac/ticket/12770 because various platforms
>> use different paths as the targets of /etc/localtime - and some times,
>> it's a doubly linked symlink.  In other cases, the file is just copied,
>> and we have to trawl through /usr/share/zoneinfo looking for a binary
>> file which matches.  There are other methods employed if these fail, but
>> I think this will suffice for our purposes.
>>
>>  Even if ICU consumed the /etc/zoneinfo file directly, or was able to
>> call the host to perform the calculations it needs, that would not
>> suffice in terms of localized content.  As I think has been noted on
>> this list before, it does not seem to be a goal of the tz database to
>> collect these translated names, and tz-link.html does link to CLDR as
>> one possible source of translations.
>>
>>  I think that this would benefit other users as well, by making zone
>> files self identifiable. I think the JDK has to do similar analysis.
>> Some JavaScript containers (Mozilla especially) now support IANA tz ids,
>> such as in
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe
>> rence/Global_Objects/DateTimeFormat#Parameters
>>
>>  Any thoughts or comments?
>>
>>  Thanks,
>>    Steven
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20170209/b7d16931/attachment.html>