2016c on illumos - problems with new Russia entries
I was about to bump TZ on illumos (the open-source inheritor of what was OpenSolaris) but I encountered these when building: "europe", line 2551: warning: time zone abbreviation differs from POSIX standard (+03) "europe", line 2552: warning: time zone abbreviation differs from POSIX standard (+05) (rule from "europe", line 599) "europe", line 2552: warning: time zone abbreviation differs from POSIX standard (+04) (rule from "europe", line 600) "europe", line 2627: warning: time zone abbreviation differs from POSIX standard (+03) "europe", line 2628: warning: time zone abbreviation differs from POSIX standard (+05) (rule from "europe", line 599) "europe", line 2628: warning: time zone abbreviation differs from POSIX standard (+04) (rule from "europe", line 600) "europe", line 2630: warning: time zone abbreviation differs from POSIX standard (+02) (rule from "europe", line 603) "europe", line 2711: warning: time zone abbreviation differs from POSIX standard (+06) "europe", line 2712: warning: time zone abbreviation differs from POSIX standard (+08) (rule from "europe", line 599) "europe", line 2712: warning: time zone abbreviation differs from POSIX standard (+07) (rule from "europe", line 600) Now it is possible that the zic(1) utility for illumos needs some updating. OTOH, I've never had a problem until this specific update. The entries in question are (with markings): Zone Europe/Astrakhan 3:12:12 - LMT 1924 May **HERE*** 3:00 - +03 1930 Jun 21 **HERE*** 4:00 Russia +04/+05 1989 Mar 26 2:00s 3:00 Russia +03/+04 1991 Mar 31 2:00s 4:00 - +04 1992 Mar 29 2:00s 3:00 Russia +03/+04 2011 Mar 27 2:00s 4:00 - +04 2014 Oct 26 2:00s 3:00 - +03 2016 Mar 27 2:00s 4:00 - +04 Zone Europe/Ulyanovsk 3:13:36 - LMT 1919 Jul 1 2:00 **HERE*** 3:00 - +03 1930 Jun 21 **HERE*** 4:00 Russia +04/+05 1989 Mar 26 2:00s 3:00 Russia +03/+04 1991 Mar 31 2:00s **HERE*** 2:00 Russia +02/+03 1992 Jan 19 2:00s 3:00 Russia +03/+04 2011 Mar 27 2:00s 4:00 - +04 2014 Oct 26 2:00s 3:00 - +03 2016 Mar 27 2:00s 4:00 - +04 Zone Asia/Barnaul 5:35:00 - LMT 1919 Dec 10 **HERE*** 6:00 - +06 1930 Jun 21 **HERE*** 7:00 Russia +07/+08 1991 Mar 31 2:00s 6:00 Russia +06/+07 1992 Jan 19 2:00s 7:00 Russia +07/+08 1995 May 28 6:00 Russia +06/+07 2011 Mar 27 2:00s 7:00 - +07 2014 Oct 26 2:00s 6:00 - +06 2016 Mar 27 2:00s 7:00 - +07 I checked the mailing list archives quickly, but didn't see anything about Astrakhan, so I figured nobody else has seen this yet. I'm no expert in these... I just happen to update the illumos ones for the community every time my distro (OmniOS) gets ready to ship an update. Thanks, Dan McDonald -- OmniOS Engineering
On 08/04/16 03:56, Dan McDonald wrote:
I was about to bump TZ on illumos (the open-source inheritor of what was OpenSolaris) but I encountered these when building:
"europe", line 2551: warning: time zone abbreviation differs from POSIX standard (+03) "europe", line 2552: warning: time zone abbreviation differs from POSIX standard (+05) (rule from "europe", line 599) "europe", line 2552: warning: time zone abbreviation differs from POSIX standard (+04) (rule from "europe", line 600) "europe", line 2627: warning: time zone abbreviation differs from POSIX standard (+03) "europe", line 2628: warning: time zone abbreviation differs from POSIX standard (+05) (rule from "europe", line 599) "europe", line 2628: warning: time zone abbreviation differs from POSIX standard (+04) (rule from "europe", line 600) "europe", line 2630: warning: time zone abbreviation differs from POSIX standard (+02) (rule from "europe", line 603) "europe", line 2711: warning: time zone abbreviation differs from POSIX standard (+06) "europe", line 2712: warning: time zone abbreviation differs from POSIX standard (+08) (rule from "europe", line 599) "europe", line 2712: warning: time zone abbreviation differs from POSIX standard (+07) (rule from "europe", line 600)
Now it is possible that the zic(1) utility for illumos needs some updating. OTOH, I've never had a problem until this specific update.
The entries in question are (with markings):
Zone Europe/Astrakhan 3:12:12 - LMT 1924 May **HERE*** 3:00 - +03 1930 Jun 21 **HERE*** 4:00 Russia +04/+05 1989 Mar 26 2:00s 3:00 Russia +03/+04 1991 Mar 31 2:00s 4:00 - +04 1992 Mar 29 2:00s 3:00 Russia +03/+04 2011 Mar 27 2:00s 4:00 - +04 2014 Oct 26 2:00s 3:00 - +03 2016 Mar 27 2:00s 4:00 - +04
Zone Europe/Ulyanovsk 3:13:36 - LMT 1919 Jul 1 2:00 **HERE*** 3:00 - +03 1930 Jun 21 **HERE*** 4:00 Russia +04/+05 1989 Mar 26 2:00s 3:00 Russia +03/+04 1991 Mar 31 2:00s **HERE*** 2:00 Russia +02/+03 1992 Jan 19 2:00s 3:00 Russia +03/+04 2011 Mar 27 2:00s 4:00 - +04 2014 Oct 26 2:00s 3:00 - +03 2016 Mar 27 2:00s 4:00 - +04
Zone Asia/Barnaul 5:35:00 - LMT 1919 Dec 10 **HERE*** 6:00 - +06 1930 Jun 21 **HERE*** 7:00 Russia +07/+08 1991 Mar 31 2:00s 6:00 Russia +06/+07 1992 Jan 19 2:00s 7:00 Russia +07/+08 1995 May 28 6:00 Russia +06/+07 2011 Mar 27 2:00s 7:00 - +07 2014 Oct 26 2:00s 6:00 - +06 2016 Mar 27 2:00s 7:00 - +07
I checked the mailing list archives quickly, but didn't see anything about Astrakhan, so I figured nobody else has seen this yet.
I'm no expert in these... I just happen to update the illumos ones for the community every time my distro (OmniOS) gets ready to ship an update.
I'd just treat them as warnings. The version of zic from 2015f onwards doesn't warn about these lines. In the future, once sufficient installations of zic have been upgraded, numeric abbreviations like '+04' in the input files will be replaced by '%z' and zic will automagically generate the numeric abbreviations. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-
On Fri, Apr 8, 2016, at 06:56, Ian Abbott wrote:
I'd just treat them as warnings. The version of zic from 2015f onwards doesn't warn about these lines.
In the future, once sufficient installations of zic have been upgraded, numeric abbreviations like '+04' in the input files will be replaced by '%z' and zic will automagically generate the numeric abbreviations.
You know, I've occasionally wondered what's the point of having a standard binary format (which has a performance cost compared to having one that uses platform-specific alignment and endianness) if you're not going to actually ship binary files.
On Apr 8, 2016, at 10:33 AM, Random832 <random832@fastmail.com> wrote:
On Fri, Apr 8, 2016, at 06:56, Ian Abbott wrote:
I'd just treat them as warnings. The version of zic from 2015f onwards doesn't warn about these lines.
In the future, once sufficient installations of zic have been upgraded, numeric abbreviations like '+04' in the input files will be replaced by '%z' and zic will automagically generate the numeric abbreviations.
You know, I've occasionally wondered what's the point of having a standard binary format (which has a performance cost compared to having one that uses platform-specific alignment and endianness) if you're not going to actually ship binary files.
It's there if you want to use it. The tzdata are useful to everyone, whether they use zic or not, whether they use the supplied zic or some other. If you don't like the binary format, you're free to make your own. If you want to avoid the design effort and don't mind the trivial performance hit, you can use the standard. paul
On Fri, Apr 8, 2016, at 11:16, Paul_Koning@Dell.com wrote:
It's there if you want to use it. The tzdata are useful to everyone, whether they use zic or not, whether they use the supplied zic or some other.
I don't understand how that answers my question, of why there are no binary packages, provided by this project, of the binary timezones. I don't see what other purpose could be served by having the binary format be architecture-independent.
I don't know why there's no binary distribution, but it's certainly useful to have an architecture independent binary standard, since it makes it much easier to write cross platform software that interprets the binaries. Having a "source" distribution is presumably useful for situations where you want to build only a subset of the dataset (e.g. in restricted memory situations), or if you have your own modifications that you patch in for whatever reason. On April 8, 2016 11:30:02 AM EDT, Random832 <random832@fastmail.com> wrote:
On Fri, Apr 8, 2016, at 11:16, Paul_Koning@Dell.com wrote:
It's there if you want to use it. The tzdata are useful to everyone, whether they use zic or not, whether they use the supplied zic or some other.
I don't understand how that answers my question, of why there are no binary packages, provided by this project, of the binary timezones. I don't see what other purpose could be served by having the binary format be architecture-independent.
Date: Fri, 08 Apr 2016 11:30:02 -0400 From: Random832 <random832@fastmail.com> Message-ID: <1460129402.1466259.572995465.27BE1D79@webmail.messagingengine.com> | I don't understand how that answers my question, of why there are no | binary packages, provided by this project, of the binary timezones. I | don't see what other purpose could be served by having the binary format | be architecture-independent. The binary format is simply a reference implementation, it serves to demonstrate that it is possible to use the supplied data to produce the supplied results. This project is not concerned in any way with any kind of distributions, it is a data collection group - we collect data about timezones, and publish it in a standard format for others to use. kre
On Apr 8, 2016, at 7:33 AM, Random832 <random832@fastmail.com> wrote:
You know, I've occasionally wondered what's the point of having a standard binary format (which has a performance cost compared to having one that uses platform-specific alignment and endianness) if you're not going to actually ship binary files.
So that a set of diskless workstations with different alignment requirements and byte orders (68k-based, SPARC-based, and x86-based) could share their time zone files on the file server. (Yes, that is the reason why I contributed the changes to tzcode, back in the 1980's, to use a standard byte order in the files; I was a developer in the OS group at Sun, and the person who picked up the tzdb at Sun, and I knew the Sun386i would be coming out.)
On 04/08/2016 07:33 AM, Random832 wrote:
You know, I've occasionally wondered what's the point of having a standard binary format (which has a performance cost compared to having one that uses platform-specific alignment and endianness) if you're not going to actually ship binary files. As Guy mentioned, there's a good reason to have an architecture-neutral binary format even if the tz project doesn't distribute them. That being said, it's a reasonable suggestion for us to distribute binary files as well. They could be in another tarball, say.
On 04/07/2016 07:56 PM, Dan McDonald wrote:
I checked the mailing list archives quickly, but didn't see anything about Astrakhan, so I figured nobody else has seen this yet.
This glitch was mentioned in the 2016b announcement <http://mm.icann.org/pipermail/tz-announce/2016-March/000036.html> as a last-minute note that I forgot to record in the NEWS file. Proposed patch attached.
On Apr 8, 2016, at 1:50 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
<0001-NEWS-Add-compatibility-note-for-2016b.patch>
Thank you. Someone also responded to me offline with a patch from Dragonfly BSD, which I've got up for review now: http://kebe.com/~danmcd/webrevs/zic-zdump/ Anyone here feel like reviewing is welcome to, but I'm not expecting anyone to do so. Thanks a ton!!! Dan
On 04/08/2016 10:52 AM, Dan McDonald wrote:
Someone also responded to me offline with a patch from Dragonfly BSD, which I've got up for review now:
A quick glance suggests that we already have those changes. It looks like Dragonfly has forked from the tzcode versions of zic.c and zdump.c. I don't know why they would do that -- it's more work for them. Perhaps you could suggest that they simply adopt the tzcode versions as-is. Similarly for illumos.
On Apr 8, 2016, at 3:17 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 04/08/2016 10:52 AM, Dan McDonald wrote:
Someone also responded to me offline with a patch from Dragonfly BSD, which I've got up for review now:
A quick glance suggests that we already have those changes.
Good! And that they didn't look WRONG to you (am I right) is encouraging.
It looks like Dragonfly has forked from the tzcode versions of zic.c and zdump.c. I don't know why they would do that -- it's more work for them. Perhaps you could suggest that they simply adopt the tzcode versions as-is. Similarly for illumos.
For us it's about the existing L10N in place. It does sound, however, like perhaps we should resync with tzcode down the road. That won't be today, however. Thank you! Dan
participants (8)
-
Dan McDonald -
Guy Harris -
Ian Abbott -
Paul Eggert -
Paul G -
Paul_Koning＠dell.com -
Random832 -
Robert Elz