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/Reference/Global_Obj... Any thoughts or comments? Thanks, Steven
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@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/ Reference/Global_Objects/DateTimeFormat#Parameters
Any thoughts or comments?
Thanks, Steven
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@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@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
On Thu, Feb 09, 2017 at 17:59:23 -0500, Arthur David Olson wrote:
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
On Thu, Feb 09, 2017 at 17:37:53 -0800, Paul Eggert wrote:
On 02/09/2017 04:44 PM, Steven R. Loomis wrote:
There are political objections to some of the zone names, so putting them in the data files might raise a few eyebrows. Wouldn't the names have been filenames elsewhere on disk, somewhere in the "zoneinfo" directory?
Not in some installations. Android, I think, does not create filenames like "America/New_York". More important, these names are not part of the format now, and standardizing them in the format would increase the likelihood of causing political irritations. And
I am pretty sure it wouldn't be the best solution to the overall set of goals being discussed in this thread, but just in case it inspires better ideas I'll throw the following thought into the ring: It occured to me that a way to avoid putting these zone names into the data file itself yet still have the data file be "uniquely" identified would be to have some process (hash?) come up with a unique, shorter-than-15-byte identifier for each zone, which could then be placed in in the existing "reserved for future use" field in the data file. Nathan ---------------------------------------------------------------------------- Nathan Stratton Treadway - nathanst@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
-----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Nathan Stratton Treadway Sent: 10 February 2017 03:54 To: tz@iana.org Subject: Re: [tz] Version in zoneinfo files?
On Thu, Feb 09, 2017 at 17:59:23 -0500, Arthur David Olson wrote:
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
On Thu, Feb 09, 2017 at 17:37:53 -0800, Paul Eggert wrote:
On 02/09/2017 04:44 PM, Steven R. Loomis wrote:
There are political objections to some of the zone names, so putting them in the data files might raise a few eyebrows. Wouldn't the names have been filenames elsewhere on disk, somewhere in the "zoneinfo" directory?
Not in some installations. Android, I think, does not create filenames like "America/New_York". More important, these names are not part of the format now, and standardizing them in the format would increase the likelihood of causing political irritations. And
I am pretty sure it wouldn't be the best solution to the overall set of goals being discussed in this thread, but just in case it inspires better ideas I'll throw the following thought into the ring:
It occured to me that a way to avoid putting these zone names into the data file itself yet still have the data file be "uniquely" identified would be to have some process (hash?) come up with a unique, shorter-than-15-byte identifier for each zone, which could then be placed in in the existing "reserved for future use" field in the data file.
Nathan
---------------------------------------------------------------------------- Nathan Stratton Treadway - nathanst@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
FWIW For a number of years I have been using a simple scheme where we have a short integer that is used as a TZ id - in an embedded environment, we record data samples with a UTC timestamp plus this id number. When the data is displayed we use a simple table, indexed directly by the short integer, to look up the full-length TZ name and display the local time when & where the data was recorded. There should be enough space in the "reserved for future use" fields to store a short and then provide the mapping table as a separate file. I've mentioned this idea a couple of times in the past, e.g. http://mm.icann.org/pipermail/tz/2013-March/018707.html and, if there was interest, would tidy up the table & code and make it available. The big problem with this scheme is that there are problems when zones are deleted - as happened in tzdata2011m when Europe/Tiraspol vanished Regards, Stephen Goudge Senior Software Engineer 390 Princesway Team Valley Gateshead Tyne & Wear NE11 0TU T +44 (0) 191 420 3015 F +44 (0) 191 420 3030 W www.petards.com ___________________________________________________________________________________________ This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud ___________________________________________________________________________________________ This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful. Petards Group plc is registered in England & Wales. Company No. 2990100 ___________________________________________________________________________________________
On 2/13/17 2:39 AM, Goudge, Stephen wrote:
-----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Nathan Stratton Treadway Sent: 10 February 2017 03:54 To: tz@iana.org Subject: Re: [tz] Version in zoneinfo files?
On Thu, Feb 09, 2017 at 17:59:23 -0500, Arthur David Olson wrote:
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 I am pretty sure it wouldn't be the best solution to the overall set of goals being discussed in this thread, but just in case it inspires better ideas I'll throw the following thought into the ring:
It occured to me that a way to avoid putting these zone names into the data file itself yet still have the data file be "uniquely" identified would be to have some process (hash?) come up with a unique, shorter-than-15-byte identifier for each zone, which could then be placed in in the existing "reserved for future use" field in the data file. FWIW For a number of years I have been using a simple scheme where we have a short integer that is used as a TZ id - in an embedded environment, we record data samples with a UTC timestamp plus this id number. When the data is displayed we use a simple table, indexed directly by the short integer, to look up the full-length TZ name and display the local time when & where the data was recorded.
There should be enough space in the "reserved for future use" fields to store a short and then provide the mapping table as a separate file.
I've mentioned this idea a couple of times in the past, e.g. http://mm.icann.org/pipermail/tz/2013-March/018707.html and, if there was interest, would tidy up the table & code and make it available. The big problem with this scheme is that there are problems when zones are deleted - as happened in tzdata2011m when Europe/Tiraspol vanished This makes some sense, however as far as goals go, it solves one problem but adds another: Locating the table of mappings. The flip side is having a new file for implementations to deal with.
-s
participants (5)
-
Arthur David Olson -
Bradley White -
Goudge, Stephen -
Nathan Stratton Treadway -
Steven R. Loomis