[tz] tzid in zoneinfo?
bww at acm.org
Thu Feb 9 23:43:55 UTC 2017
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 ...
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).
> On Thu, Feb 9, 2017 at 5:44 PM, Steven R. Loomis <srl at icu-project.org>
>> 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.
>> such as in
>> Any thoughts or comments?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz