make traditional_tarballs fails on macOS for 2022b
This is a regression from 2022a. This is on macOS 13.0 but I suspect it will fail the same way on macOS 12. Also note that macOS does not have nroff installed, but that doesn’t look like a fatal error. Debbie debbie 6:11PM tz ✓ % make traditional_tarballs { (type git) >/dev/null 2>&1 && \ V=`git describe --match '[0-9][0-9][0-9][0-9][a-z]*' \ --abbrev=7 --dirty` || \ if test 'unknown' = unknown && V=`cat version`; then \ case $V in *-dirty);; *) V=$V-dirty;; esac; \ else \ V='unknown'; \ fi; } && \ printf '%s\n' "$V" >version.out mv version.out version awk -v EXPIRES_LINE=0 \ -f leapseconds.awk leap-seconds.list >leapseconds.out mv leapseconds.out leapseconds LC_ALL=C sh workman.sh `expr tzselect.8.txt : '\(.*\)\.txt$'` >tzselect.8.txt.out workman.sh: line 16: nroff: command not found mv tzselect.8.txt.out tzselect.8.txt LC_ALL=C sh workman.sh `expr zic.8.txt : '\(.*\)\.txt$'` >zic.8.txt.out workman.sh: line 16: nroff: command not found mv zic.8.txt.out zic.8.txt awk \ -v DATAFORM=`expr main.zi : '\(.*\).zi'` \ -v PACKRATDATA='' \ -v PACKRATLIST='' \ -f ziguard.awk \ africa antarctica asia australasia europe northamerica southamerica etcetera factory backward >main.zi.out awk: syntax error at source line 110 source file ziguard.awk context is stdoff_column = 2 * /^Zone/ >>> + <<< 1 awk: illegal statement at source line 110 source file ziguard.awk awk: illegal statement at source line 110 source file ziguard.awk make: *** [main.zi] Error 2
I tried it on macOS 12.5 and while nroff is present there, it fails with the same syntax error in awk. I tried it with a clean fresh clone, too. To be more clear, "make traditional_tarballs" works fine with a checkout of 2022a on the same system where 2022b fails. Debbie
On Aug 10, 2022, at 6:15 PM, Deborah Goldsmith via tz <tz@iana.org> wrote:
This is a regression from 2022a. This is on macOS 13.0 but I suspect it will fail the same way on macOS 12. Also note that macOS does not have nroff installed, but that doesn’t look like a fatal error.
Debbie
debbie 6:11PM tz ✓ % make traditional_tarballs { (type git) >/dev/null 2>&1 && \ V=`git describe --match '[0-9][0-9][0-9][0-9][a-z]*' \ --abbrev=7 --dirty` || \ if test 'unknown' = unknown && V=`cat version`; then \ case $V in *-dirty);; *) V=$V-dirty;; esac; \ else \ V='unknown'; \ fi; } && \ printf '%s\n' "$V" >version.out mv version.out version awk -v EXPIRES_LINE=0 \ -f leapseconds.awk leap-seconds.list >leapseconds.out mv leapseconds.out leapseconds LC_ALL=C sh workman.sh `expr tzselect.8.txt : '\(.*\)\.txt$'` >tzselect.8.txt.out workman.sh: line 16: nroff: command not found mv tzselect.8.txt.out tzselect.8.txt LC_ALL=C sh workman.sh `expr zic.8.txt : '\(.*\)\.txt$'` >zic.8.txt.out workman.sh: line 16: nroff: command not found mv zic.8.txt.out zic.8.txt awk \ -v DATAFORM=`expr main.zi : '\(.*\).zi'` \ -v PACKRATDATA='' \ -v PACKRATLIST='' \ -f ziguard.awk \ africa antarctica asia australasia europe northamerica southamerica etcetera factory backward >main.zi.out awk: syntax error at source line 110 source file ziguard.awk context is stdoff_column = 2 * /^Zone/ >>> + <<< 1 awk: illegal statement at source line 110 source file ziguard.awk awk: illegal statement at source line 110 source file ziguard.awk make: *** [main.zi] Error 2
Thanks for reporting the problem. This appears to be a bug in macOS awk, as it is reporting a syntax error here: stdoff_column = 2 * /^Zone/ + 1 even though POSIX says this is a valid awk statement. I don't observe the bug on FreeBSD 13.0, where "awk --version" reports "awk version 20190529 (FreeBSD)". Please try the attached patch, which I have installed in the development repository. I hope it works around the macOS bug, but I don't have easy access to macOS to try it. If this patch works for you, please file a bug report with whoever is maintaining 'awk' on macOS, as statements like the above should work. If I'm right about the bug, then to build without the patch you can install a working 'awk' on your system (e.g., FreeBSD or GNU 'awk'), or run 'make traditional_tarballs' on a working platform (e.g., FreeBSD or GNU/Linux) and then transport the resulting tarball to macOS.
On 2022-08-11 10:26:44 (+0800), Paul Eggert via tz wrote:
Thanks for reporting the problem. This appears to be a bug in macOS awk, as it is reporting a syntax error here:
stdoff_column = 2 * /^Zone/ + 1
even though POSIX says this is a valid awk statement.
I don't observe the bug on FreeBSD 13.0, where "awk --version" reports "awk version 20190529 (FreeBSD)".
I do see this on FreeBSD 13.1 which has awk version 20210215.
Please try the attached patch, which I have installed in the development repository. I hope it works around the macOS bug, but I don't have easy access to macOS to try it. If this patch works for you, please file a bug report with whoever is maintaining 'awk' on macOS, as statements like the above should work.
This patch works on FreeBSD. Thanks for the quick fix! Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On 2022-08-11 11:08:29 (+0800), Guy Harris wrote:
On Aug 10, 2022, at 7:38 PM, Philip Paeps via tz <tz@iana.org> wrote:
I do see this on FreeBSD 13.1 which has awk version 20210215.
Perhaps that's a bug that snuck into the One True Awk at some point (I'm guessing that FreeBSD uses it; macOS does).
Looks like it. macOS 12.5 uses awk version 20200816. Since Paul didn't observe the problem on FreeBSD 13.0, which has awk version 20190529, the problem must have been introduced somewhen between those two dates. A quick eyegrep of the FIXES file in the onetrueawk repository doesn't show throw up immediately obvious, unfortunately. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Both traditional_tarballs and rearguard_tarballs build with no problems with the latest commit in the development repo. Thanks, Debbie
On Aug 10, 2022, at 7:26 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Thanks for reporting the problem. This appears to be a bug in macOS awk, as it is reporting a syntax error here:
stdoff_column = 2 * /^Zone/ + 1
even though POSIX says this is a valid awk statement.
I don't observe the bug on FreeBSD 13.0, where "awk --version" reports "awk version 20190529 (FreeBSD)".
Please try the attached patch, which I have installed in the development repository. I hope it works around the macOS bug, but I don't have easy access to macOS to try it. If this patch works for you, please file a bug report with whoever is maintaining 'awk' on macOS, as statements like the above should work.
If I'm right about the bug, then to build without the patch you can install a working 'awk' on your system (e.g., FreeBSD or GNU 'awk'), or run 'make traditional_tarballs' on a working platform (e.g., FreeBSD or GNU/Linux) and then transport the resulting tarball to macOS.<0001-Work-around-macOS-awk-bug.patch>
Given that this is a bug that affects multiple systems (macOS, FreeBSD 13.1) please consider releasing a new version with the fix. Thanks, Debbie
On Aug 10, 2022, at 11:35 PM, Deborah Goldsmith via tz <tz@iana.org> wrote:
Both traditional_tarballs and rearguard_tarballs build with no problems with the latest commit in the development repo.
Thanks, Debbie
On Aug 10, 2022, at 7:26 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Thanks for reporting the problem. This appears to be a bug in macOS awk, as it is reporting a syntax error here:
stdoff_column = 2 * /^Zone/ + 1
even though POSIX says this is a valid awk statement.
I don't observe the bug on FreeBSD 13.0, where "awk --version" reports "awk version 20190529 (FreeBSD)".
Please try the attached patch, which I have installed in the development repository. I hope it works around the macOS bug, but I don't have easy access to macOS to try it. If this patch works for you, please file a bug report with whoever is maintaining 'awk' on macOS, as statements like the above should work.
If I'm right about the bug, then to build without the patch you can install a working 'awk' on your system (e.g., FreeBSD or GNU 'awk'), or run 'make traditional_tarballs' on a working platform (e.g., FreeBSD or GNU/Linux) and then transport the resulting tarball to macOS.<0001-Work-around-macOS-awk-bug.patch>
On 8/10/22 23:44, Deborah Goldsmith wrote:
Given that this is a bug that affects multiple systems (macOS, FreeBSD 13.1) please consider releasing a new version with the fix.
Before doing a new release could you explain a bit more what went wrong? I wonder whether we're merely papering over a deeper problem. macOS users don't need to run "make traditional_tarballs" to get traditional tarballs, as they can get these tarballs prebuilt from upstream: https://data.iana.org/time-zones/releases/tzcode2022b.tar.gz https://data.iana.org/time-zones/releases/tzdata2022b.tar.gz So I expect there's something more going on, such as modifying the code or data before generating the traditional tarballs as part of some script. What sort of modifications or script is that? And some process is modifying the source or data, can't that process also apply the patch as part of the modification? Also, I'm puzzled by why workman.sh was invoked, as I mentioned in my recent email to Guy. Is that due to the modifications mentioned above?
We don’t modify the source. We do make the rearguard tarballs, which suffer from the same awk problem, and which can’t be downloaded. As of macOS 13 public betas, it appears that nroff is no longer distributed as part of macOS. macOS 13 public betas include mandoc. (I can’t speak to what the final content of macOS 13 GM will be.) Debbie
On Aug 11, 2022, at 12:08 AM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 8/10/22 23:44, Deborah Goldsmith wrote:
Given that this is a bug that affects multiple systems (macOS, FreeBSD 13.1) please consider releasing a new version with the fix.
Before doing a new release could you explain a bit more what went wrong? I wonder whether we're merely papering over a deeper problem.
macOS users don't need to run "make traditional_tarballs" to get traditional tarballs, as they can get these tarballs prebuilt from upstream:
https://data.iana.org/time-zones/releases/tzcode2022b.tar.gz https://data.iana.org/time-zones/releases/tzdata2022b.tar.gz
So I expect there's something more going on, such as modifying the code or data before generating the traditional tarballs as part of some script. What sort of modifications or script is that? And some process is modifying the source or data, can't that process also apply the patch as part of the modification?
Also, I'm puzzled by why workman.sh was invoked, as I mentioned in my recent email to Guy. Is that due to the modifications mentioned above?
macOS (and FreeBSD) use onetrueawk (https://github.com/onetrueawk/awk.git). I tried this with their latest commit, and the same failure occurs. So 2022b is incompatible with any platform that uses onetrueawk. This includes FreeBSD 13.1 and macOS (I don’t know what other platform-clients might be). I filed this issue against onetrueawk, but there is no guarantee it will be fixed any time soon: https://github.com/onetrueawk/awk/issues/149 Meanwhile, there is no way to get rearguard_tarballs on those platforms. Debbie
On Aug 11, 2022, at 12:15 AM, Deborah Goldsmith via tz <tz@iana.org> wrote:
We don’t modify the source. We do make the rearguard tarballs, which suffer from the same awk problem, and which can’t be downloaded.
As of macOS 13 public betas, it appears that nroff is no longer distributed as part of macOS. macOS 13 public betas include mandoc. (I can’t speak to what the final content of macOS 13 GM will be.)
Debbie
On Aug 11, 2022, at 12:08 AM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 8/10/22 23:44, Deborah Goldsmith wrote:
Given that this is a bug that affects multiple systems (macOS, FreeBSD 13.1) please consider releasing a new version with the fix.
Before doing a new release could you explain a bit more what went wrong? I wonder whether we're merely papering over a deeper problem.
macOS users don't need to run "make traditional_tarballs" to get traditional tarballs, as they can get these tarballs prebuilt from upstream:
https://data.iana.org/time-zones/releases/tzcode2022b.tar.gz https://data.iana.org/time-zones/releases/tzdata2022b.tar.gz
So I expect there's something more going on, such as modifying the code or data before generating the traditional tarballs as part of some script. What sort of modifications or script is that? And some process is modifying the source or data, can't that process also apply the patch as part of the modification?
Also, I'm puzzled by why workman.sh was invoked, as I mentioned in my recent email to Guy. Is that due to the modifications mentioned above?
I don't observe the bug on FreeBSD 13.0, where "awk --version" reports "awk version 20190529 (FreeBSD)".
I got this comment from one of the maintainers of onetrueawk:
hi deborah, thanks for the report. I have a freebsd13 at hand, 20190529 release gives the same error.I have tested earlier versions as well. so it is not a change in our release of awk that now fails the IANA tz database build.
Is it possible you built with something other than onetrueawk? Debbie
On Aug 10, 2022, at 7:26 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
Thanks for reporting the problem. This appears to be a bug in macOS awk, as it is reporting a syntax error here:
stdoff_column = 2 * /^Zone/ + 1
even though POSIX says this is a valid awk statement.
I don't observe the bug on FreeBSD 13.0, where "awk --version" reports "awk version 20190529 (FreeBSD)".
Please try the attached patch, which I have installed in the development repository. I hope it works around the macOS bug, but I don't have easy access to macOS to try it. If this patch works for you, please file a bug report with whoever is maintaining 'awk' on macOS, as statements like the above should work.
If I'm right about the bug, then to build without the patch you can install a working 'awk' on your system (e.g., FreeBSD or GNU 'awk'), or run 'make traditional_tarballs' on a working platform (e.g., FreeBSD or GNU/Linux) and then transport the resulting tarball to macOS.<0001-Work-around-macOS-awk-bug.patch>
On 8/11/22 16:40, Deborah Goldsmith wrote:
Is it possible you built with something other than onetrueawk?
I looked into that, and it turns out I made a different mistake: on FreeBSD 13 I accidentally tested with 2020b not 2022b. So you're right, 2022b's make_traditional_tarballs also fails on FreeBSD 13. Sorry about that mistake.
We don’t modify the source. We do make the rearguard tarballs, which suffer from the same awk problem, and which can’t be downloaded.
Oh, I thought you were running "make traditional_tarballs" (the subject line of this thread). If you're running "make rearguard_tarballs" I think I now see why it's needed. One worry is that if we release a new version 2022c right away with the installed patch, we'll run into some other issue on macOS that would mean we'd need to release 2022d, 2022e, etc. To prevent that, can you please try running the rest of your build procedure with the rearguard tarball? If that works, we can release 2022c with more confidence. To help you try that out, I built the rearguard tarball and you can pick it up here temporarily: https://www.cs.ucla.edu/~eggert/tz/tzdata2022b-rearguard.tar.gz Here's the output of 'sha512sum' on it: e9470bdf35349080143c5c36bd6460d45ad506b2b3bd6ce192df1cae1739a945dbf4d4b128ae0f8026e4187dcd2e25a0b3cb2a74be820406f99e4a895d31e3ed tzdata2022b-rearguard.tar.gz and you can find the GPG signed checksum here: https://www.cs.ucla.edu/~eggert/tz/tzdata2022b-rearguard.tar.gz.asc
Thanks, I will go through the process in the morning! Debbie
On Aug 11, 2022, at 6:28 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 8/11/22 16:40, Deborah Goldsmith wrote:
Is it possible you built with something other than onetrueawk?
I looked into that, and it turns out I made a different mistake: on FreeBSD 13 I accidentally tested with 2020b not 2022b. So you're right, 2022b's make_traditional_tarballs also fails on FreeBSD 13. Sorry about that mistake.
We don’t modify the source. We do make the rearguard tarballs, which suffer from the same awk problem, and which can’t be downloaded.
Oh, I thought you were running "make traditional_tarballs" (the subject line of this thread). If you're running "make rearguard_tarballs" I think I now see why it's needed.
One worry is that if we release a new version 2022c right away with the installed patch, we'll run into some other issue on macOS that would mean we'd need to release 2022d, 2022e, etc. To prevent that, can you please try running the rest of your build procedure with the rearguard tarball? If that works, we can release 2022c with more confidence.
To help you try that out, I built the rearguard tarball and you can pick it up here temporarily:
https://www.cs.ucla.edu/~eggert/tz/tzdata2022b-rearguard.tar.gz
Here's the output of 'sha512sum' on it:
e9470bdf35349080143c5c36bd6460d45ad506b2b3bd6ce192df1cae1739a945dbf4d4b128ae0f8026e4187dcd2e25a0b3cb2a74be820406f99e4a895d31e3ed tzdata2022b-rearguard.tar.gz
and you can find the GPG signed checksum here:
https://www.cs.ucla.edu/~eggert/tz/tzdata2022b-rearguard.tar.gz.asc
I am seeing unexpected binary differences in generated zoneinfo files that (in theory) should not differ from 2022a. Here are the binary differences minus what’s listed in NEWS: modified: zoneinfo/Africa/Casablanca modified: zoneinfo/Africa/El_Aaiun modified: zoneinfo/America/New_York modified: zoneinfo/Asia/Jakarta modified: zoneinfo/Europe/Gibraltar modified: zoneinfo/Europe/Guernsey modified: zoneinfo/Europe/Isle_of_Man modified: zoneinfo/Europe/Jersey modified: zoneinfo/Europe/London modified: zoneinfo/Europe/Madrid modified: zoneinfo/Europe/Malta modified: zoneinfo/Europe/Rome modified: zoneinfo/Europe/San_Marino modified: zoneinfo/Europe/Simferopol modified: zoneinfo/Europe/Vatican modified: zoneinfo/GB modified: zoneinfo/Pacific/Easter modified: zoneinfo/US/Eastern I tried to be careful to remove synonyms of the zones listed as changed in NEWS, but as far as I can tell none of the above zones should have changed at all. Is there a tool that can dump transitions in zoneinfo files that have *not* been installed in the standard platform location? zdump only works on zoneinfo files that have been installed. Thanks, Debbie
On Aug 11, 2022, at 10:36 PM, Deborah Goldsmith via tz <tz@iana.org> wrote:
Thanks, I will go through the process in the morning!
Debbie
On Aug 11, 2022, at 6:28 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 8/11/22 16:40, Deborah Goldsmith wrote:
Is it possible you built with something other than onetrueawk?
I looked into that, and it turns out I made a different mistake: on FreeBSD 13 I accidentally tested with 2020b not 2022b. So you're right, 2022b's make_traditional_tarballs also fails on FreeBSD 13. Sorry about that mistake.
We don’t modify the source. We do make the rearguard tarballs, which suffer from the same awk problem, and which can’t be downloaded.
Oh, I thought you were running "make traditional_tarballs" (the subject line of this thread). If you're running "make rearguard_tarballs" I think I now see why it's needed.
One worry is that if we release a new version 2022c right away with the installed patch, we'll run into some other issue on macOS that would mean we'd need to release 2022d, 2022e, etc. To prevent that, can you please try running the rest of your build procedure with the rearguard tarball? If that works, we can release 2022c with more confidence.
To help you try that out, I built the rearguard tarball and you can pick it up here temporarily:
https://www.cs.ucla.edu/~eggert/tz/tzdata2022b-rearguard.tar.gz
Here's the output of 'sha512sum' on it:
e9470bdf35349080143c5c36bd6460d45ad506b2b3bd6ce192df1cae1739a945dbf4d4b128ae0f8026e4187dcd2e25a0b3cb2a74be820406f99e4a895d31e3ed tzdata2022b-rearguard.tar.gz
and you can find the GPG signed checksum here:
https://www.cs.ucla.edu/~eggert/tz/tzdata2022b-rearguard.tar.gz.asc
On 8/12/22 10:55, Deborah Goldsmith wrote:
zdump only works on zoneinfo files that have been installed
zdump should work on any file name beginning with "/", even if it's not installed. On Ubuntu: $ cp /usr/share/zoneinfo/right/America/Los_Angeles /tmp/xxx $ zdump -V -c 2017,2018 /tmp/xxx /tmp/xxx Sat Dec 31 23:59:60 2016 UT = Sat Dec 31 15:59:60 2016 PST isdst=0 gmtoff=-28800 /tmp/xxx Sun Jan 1 00:00:00 2017 UT = Sat Dec 31 16:00:00 2016 PST isdst=0 gmtoff=-28800 /tmp/xxx Sun Mar 12 09:59:59 2017 UT = Sun Mar 12 01:59:59 2017 PST isdst=0 gmtoff=-28800 /tmp/xxx Sun Mar 12 10:00:00 2017 UT = Sun Mar 12 03:00:00 2017 PDT isdst=1 gmtoff=-25200 /tmp/xxx Sun Nov 5 08:59:59 2017 UT = Sun Nov 5 01:59:59 2017 PDT isdst=1 gmtoff=-25200 /tmp/xxx Sun Nov 5 09:00:00 2017 UT = Sun Nov 5 01:00:00 2017 PST isdst=0 gmtoff=-28800
OK, I compared the two different versions of New_York and the transitions are identical. Could anything have changed about the binary format? I’ve never seen zoneinfo files fail to compare without a semantic difference before. I will continue investigating. Debbie
On Aug 12, 2022, at 11:03 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 8/12/22 10:55, Deborah Goldsmith wrote:
zdump only works on zoneinfo files that have been installed
zdump should work on any file name beginning with "/", even if it's not installed. On Ubuntu:
$ cp /usr/share/zoneinfo/right/America/Los_Angeles /tmp/xxx $ zdump -V -c 2017,2018 /tmp/xxx /tmp/xxx Sat Dec 31 23:59:60 2016 UT = Sat Dec 31 15:59:60 2016 PST isdst=0 gmtoff=-28800 /tmp/xxx Sun Jan 1 00:00:00 2017 UT = Sat Dec 31 16:00:00 2016 PST isdst=0 gmtoff=-28800 /tmp/xxx Sun Mar 12 09:59:59 2017 UT = Sun Mar 12 01:59:59 2017 PST isdst=0 gmtoff=-28800 /tmp/xxx Sun Mar 12 10:00:00 2017 UT = Sun Mar 12 03:00:00 2017 PDT isdst=1 gmtoff=-25200 /tmp/xxx Sun Nov 5 08:59:59 2017 UT = Sun Nov 5 01:59:59 2017 PDT isdst=1 gmtoff=-25200 /tmp/xxx Sun Nov 5 09:00:00 2017 UT = Sun Nov 5 01:00:00 2017 PST isdst=0 gmtoff=-28800
I just remembered that I am using a newer version of zic than when 2022a was built, so that might be it. I’ll see if I can reproduce the issue with the old zic. If not, then the binary differences are just an artifact. Thanks, Debbie
On Aug 12, 2022, at 11:09 AM, Deborah Goldsmith via tz <tz@iana.org> wrote:
OK, I compared the two different versions of New_York and the transitions are identical. Could anything have changed about the binary format? I’ve never seen zoneinfo files fail to compare without a semantic difference before.
I will continue investigating.
Debbie
On Aug 12, 2022, at 11:03 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 8/12/22 10:55, Deborah Goldsmith wrote:
zdump only works on zoneinfo files that have been installed
zdump should work on any file name beginning with "/", even if it's not installed. On Ubuntu:
$ cp /usr/share/zoneinfo/right/America/Los_Angeles /tmp/xxx $ zdump -V -c 2017,2018 /tmp/xxx /tmp/xxx Sat Dec 31 23:59:60 2016 UT = Sat Dec 31 15:59:60 2016 PST isdst=0 gmtoff=-28800 /tmp/xxx Sun Jan 1 00:00:00 2017 UT = Sat Dec 31 16:00:00 2016 PST isdst=0 gmtoff=-28800 /tmp/xxx Sun Mar 12 09:59:59 2017 UT = Sun Mar 12 01:59:59 2017 PST isdst=0 gmtoff=-28800 /tmp/xxx Sun Mar 12 10:00:00 2017 UT = Sun Mar 12 03:00:00 2017 PDT isdst=1 gmtoff=-25200 /tmp/xxx Sun Nov 5 08:59:59 2017 UT = Sun Nov 5 01:59:59 2017 PDT isdst=1 gmtoff=-25200 /tmp/xxx Sun Nov 5 09:00:00 2017 UT = Sun Nov 5 01:00:00 2017 PST isdst=0 gmtoff=-28800
On 8/12/22 11:09, Deborah Goldsmith wrote:
OK, I compared the two different versions of New_York and the transitions are identical. Could anything have changed about the binary format?
Yes, TZif form is not completely determined by the input (e.g., time types can be renumbered) so it's quite possible for two TZif files to have identical effects even though they're not byte-for-byte the same.
It’s not the version of zic; I get the same changes when I built with the old zic. So something in the input has changed, but it seems harmless. I will spot-check some more of the unexpectedly changed zones. Thanks, Debbie
On Aug 12, 2022, at 11:22 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 8/12/22 11:09, Deborah Goldsmith wrote:
OK, I compared the two different versions of New_York and the transitions are identical. Could anything have changed about the binary format?
Yes, TZif form is not completely determined by the input (e.g., time types can be renumbered) so it's quite possible for two TZif files to have identical effects even though they're not byte-for-byte the same.
OK, I checked New York, London, Rome, Madrid, and Jakarta; there were no differences in the output from zdump. Also, I verified that the changes in America/Santiago were as expected. So I think there’s not a problem. If you’re curious, I have an app that does binary diffs (Hex Fiend) and looking through New York, it looks like single byte values being changed by +1 or -1 here and there (which fits your point about numbering), plus two 6-byte deletions (or insertions, I can’t tell which is which since the files have the same name). The six byte sequences look like this: B9B00004FFFF B9B00008FFFF Based on this testing, I think you can go ahead with 2022c; I can build real zoneinfo files and they appear to be correct. Thanks, Debbie
On Aug 12, 2022, at 11:33 AM, Deborah Goldsmith via tz <tz@iana.org> wrote:
It’s not the version of zic; I get the same changes when I built with the old zic. So something in the input has changed, but it seems harmless. I will spot-check some more of the unexpectedly changed zones.
Thanks, Debbie
On Aug 12, 2022, at 11:22 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 8/12/22 11:09, Deborah Goldsmith wrote:
OK, I compared the two different versions of New_York and the transitions are identical. Could anything have changed about the binary format?
Yes, TZif form is not completely determined by the input (e.g., time types can be renumbered) so it's quite possible for two TZif files to have identical effects even though they're not byte-for-byte the same.
Is there still a plan for a release with a fix in it? Thanks, Debbie
On Aug 12, 2022, at 11:56 AM, Deborah Goldsmith via tz <tz@iana.org> wrote:
OK, I checked New York, London, Rome, Madrid, and Jakarta; there were no differences in the output from zdump. Also, I verified that the changes in America/Santiago were as expected. So I think there’s not a problem.
If you’re curious, I have an app that does binary diffs (Hex Fiend) and looking through New York, it looks like single byte values being changed by +1 or -1 here and there (which fits your point about numbering), plus two 6-byte deletions (or insertions, I can’t tell which is which since the files have the same name). The six byte sequences look like this:
B9B00004FFFF B9B00008FFFF
Based on this testing, I think you can go ahead with 2022c; I can build real zoneinfo files and they appear to be correct.
Thanks, Debbie
On Aug 12, 2022, at 11:33 AM, Deborah Goldsmith via tz <tz@iana.org> wrote:
It’s not the version of zic; I get the same changes when I built with the old zic. So something in the input has changed, but it seems harmless. I will spot-check some more of the unexpectedly changed zones.
Thanks, Debbie
On Aug 12, 2022, at 11:22 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 8/12/22 11:09, Deborah Goldsmith wrote:
OK, I compared the two different versions of New_York and the transitions are identical. Could anything have changed about the binary format?
Yes, TZif form is not completely determined by the input (e.g., time types can be renumbered) so it's quite possible for two TZif files to have identical effects even though they're not byte-for-byte the same.
Thanks! Debbie
On Aug 15, 2022, at 1:07 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 8/15/22 10:43, Deborah Goldsmith wrote:
Is there still a plan for a release with a fix in it?
Yes, I plan to make a new release shortly, with only minor editorial changes from what's on GitHub now.
On 8/12/22 10:55, Deborah Goldsmith wrote:
modified: zoneinfo/Africa/Casablanca modified: zoneinfo/Africa/El_Aaiun
For these files, I see a difference in that in 2022b rearguard, times after 2087 are marked as daylight-saving time (tm_isdst = 1) whereas 2022a rearguard marks them as standard time (tm_isdst = 0). Other than tm_isdst all timestamps are equivalent. This is a consequence of this patch: https://mm.icann.org/pipermail/tz/2022-May/031420.html which reverted to 2021e behavior in this department.
modified: zoneinfo/America/New_York
I don't see a difference here, so this one is more worrisome. I suggest investigating this one more thoroughly on your end.
On Aug 10, 2022, at 6:15 PM, Deborah Goldsmith via tz <tz@iana.org> wrote:
Also note that macOS does not have nroff installed, but that doesn’t look like a fatal error.
It appears that macOS has joined Team Mandoc (at least as of Big Sur, if not earlier): https://mandoc.bsd.lv https://en.wikipedia.org/wiki/Mandoc so perhaps workman.sh should take the formatting command as an argument and Makefile should offer a choice of "nroff" or "mandoc" as the command. ("macOS, SUN Solaris, and *IRIX*"?)
On 8/10/22 19:31, Guy Harris via tz wrote:
workman.sh should take the formatting command as an argument and Makefile should offer a choice of "nroff" or "mandoc" as the command
I took a crack at doing something along those lines by installing the attached. This doesn't have a Makefile option; it tries to intuit the right thing without bothering the installer. Since workman.sh is not using POSIX-standardized commands and this is a messy area (mandoc doesn't emulate nroff well enough to be perfect here, among other things it mishandles .ti) I figured giving people options would be more trouble than it's worth. It does puzzle me that workman.sh was called at all. If I run "make traditional_tarballs" from a freshly extracted distribution, workman.sh is not executed. I guess the man page source is being updated for some reason, but I don't know what that reason is.
participants (4)
-
Deborah Goldsmith -
Guy Harris -
Paul Eggert -
Philip Paeps