<div dir="ltr"><div dir="ltr"></div><div>> I know Unicode CLDR feel the same way: <a href="https://mail.openjdk.java.net/pipermail/i18n-dev/2021-September/004506.html" rel="noreferrer" target="_blank">https://mail.openjdk.java.net/pipermail/i18n-dev/2021-September/004506.html</a></div><div><br></div><div>A single mail thread with no replies (as of now) is hardly evidence of Unicode CLDR feeling any type of way. We should be mindful not to insinuate things.</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 10:59 AM Stephen Colebourne via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think all of us downstream are in a real pickle because of this. I<br>
don't want the 9 link merges in 2021b but I do want the Samoa change.<br>
I know Unicode CLDR feel the same way:<br>
<a href="https://mail.openjdk.java.net/pipermail/i18n-dev/2021-September/004506.html" rel="noreferrer" target="_blank">https://mail.openjdk.java.net/pipermail/i18n-dev/2021-September/004506.html</a><br>
<br>
I am currently testing a release of Joda-Time based off a fork of tzdb:<br>
<a href="https://github.com/JodaOrg/tz" rel="noreferrer" target="_blank">https://github.com/JodaOrg/tz</a><br>
(The link merges are complex to undo, so I am not yet certain the repo<br>
is correct)<br>
<br>
I know there is another fork here:<br>
<a href="https://github.com/derickr/tz-stable" rel="noreferrer" target="_blank">https://github.com/derickr/tz-stable</a><br>
<br>
I don't consider either of these to be good solutions for the short<br>
term, or particularly viable in the long term.<br>
<br>
Feel free to use one of the repos above if it helps you. And hope that<br>
upcoming discussions yield a good outcome.<br>
<br>
thanks<br>
Stephen<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Tue, 28 Sept 2021 at 18:02, Paul Ganssle via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> wrote:<br>
><br>
> For those on the list who re-package this, what did / do you plan to<br>
> release? A version using `PACKRATDATA=backzone`, or no?<br>
><br>
> Normally I cut releases immediately after the announcement for Python's<br>
> tzdata, but the uncertainty caused by Paul's inclusion of some of the<br>
> controversial changes has led me to delay (sorry Samoans, please send<br>
> letters to your representatives).<br>
><br>
> I suspect that people who need backzone / packrat data for instrumental<br>
> purposes will need to be very clear on what version they are getting<br>
> (e.g. build from source), but I suspect that there a decent number of<br>
> test suites out there using the pre-1970 data to exercise their<br>
> TZ-handling code (from other comments on the thread I'm pretty sure this<br>
> is exactly why the data are included despite their unreliability), and<br>
> inconsistencies in the data can cause significant problems for this<br>
> application — particularly when there is no reliable way to determine<br>
> what version of the database your TZif files are coming from.<br>
><br>
> I'd like to try and be as consistent as possible with what the majority<br>
> of repackagers are doing, so I'm assuming I should go ahead with a<br>
> standard build, but if a good fraction of people chose to semi-fork by<br>
> using the provided make file option, that would be fine with me as well<br>
> (and presumably would be better for people who have hard-coded<br>
> transitions into their applications anyway). Anyone tracking who did<br>
> what who could weigh in on this?<br>
><br>
> Thanks,<br>
><br>
> Paul<br>
><br>
> On 9/24/21 20:58, Paul Eggert via tz-announce via tz wrote:<br>
> > The 2021b release of the tz code and data is available.<br>
> ><br>
> > Partly because it's been so long since 2021a, this release has many<br>
> > changes, noted below. In one area, noted "Merge more location-based<br>
> > Zones" below, the mailing list has had significant trouble coming to a<br>
> > long-term consensus. Because we should publish something before the<br>
> > Samoa change takes effect, this release contains just one step towards<br>
> > making tzdb fairer and more equitable in future releases.<br>
> ><br>
> > This release reflects the following changes, which were either<br>
> > circulated on the tz mailing list or are relatively minor technical or<br>
> > administrative changes:<br>
> ><br>
> > Briefly:<br>
> > Jordan now starts DST on February's last Thursday.<br>
> > Samoa no longer observes DST.<br>
> > Merge more location-based Zones whose timestamps agree since 1970.<br>
> > Move some backward-compatibility links to 'backward'.<br>
> > Rename Pacific/Enderbury to Pacific/Kanton.<br>
> > Correct many pre-1993 transitions in Malawi, Portugal, etc.<br>
> > zic now creates each output file or link atomically.<br>
> > zic -L no longer omits the POSIX TZ string in its output.<br>
> > zic fixes for truncation and leap second table expiration.<br>
> > zic now follows POSIX for TZ strings using all-year DST.<br>
> > Fix some localtime crashes and bugs in obscure cases.<br>
> > zdump -v now outputs more-useful boundary cases.<br>
> > tzfile.5 better matches a draft successor to RFC 8536.<br>
> > A new file SECURITY.<br>
> ><br>
> > This release is prompted by recent announcements by Jordan and Samoa.<br>
> > It incorporates many other changes that had accumulated since 2021a.<br>
> > However, it omits most proposed changes that merged all Zones<br>
> > agreeing since 1970, as concerns were raised about doing too many of<br>
> > these changes at once. It does keeps some of these changes in the<br>
> > interest of making tzdb more equitable one step at a time; see<br>
> > "Merge more location-based Zones" below.<br>
> ><br>
> > Changes to future timestamps<br>
> ><br>
> > Jordan now starts DST on February's last Thursday.<br>
> > (Thanks to Steffen Thorsen.)<br>
> ><br>
> > Samoa no longer observes DST. (Thanks to Geoffrey D. Bennett.)<br>
> ><br>
> > Changes to zone name<br>
> ><br>
> > Rename Pacific/Enderbury to Pacific/Kanton. When we added<br>
> > Enderbury in 1993, we did not know that it is uninhabited and that<br>
> > Kanton (population two dozen) is the only inhabited location in<br>
> > that timezone. The old name is now a backward-compatility link.<br>
> ><br>
> > Changes to past timestamps<br>
> ><br>
> > Correct many pre-1993 transitions, fixing entries originally<br>
> > derived from Shanks, Whitman, and Mundell. The fixes include:<br>
> > - Barbados: standard time was introduced in 1911, not 1932; and<br>
> > DST was observed in 1942-1944<br>
> > - Cook Islands: In 1899 they switched from east to west of GMT,<br>
> > celebrating Christmas for two days. They (and Niue) switched<br>
> > to standard time in 1952, not 1901.<br>
> > - Guyana: corrected LMT for Georgetown; the introduction of<br>
> > standard time in 1911, not 1915; and corrections to 1975 and<br>
> > 1992 transitions<br>
> > - Kanton: uninhabited before 1937-08-31<br>
> > - Niue: only observed -11:20 from 1952 through 1964, then went to<br>
> > -11 instead of -11:30<br>
> > - Portugal: DST was observed in 1950<br>
> > - Tonga: corrected LMT; the introduction of standard time in 1945,<br>
> > not 1901; and corrections to the transition from +12:20 to +13<br>
> > in 1961, not 1941<br>
> > Additional fixes to entries in the 'backzone' file include:<br>
> > - Enderbury: inhabited only 1860/1885 and 1938-03-06/1942-02-09<br>
> > - The Gambia: 1933 and 1942 transitions<br>
> > - Malawi: several 1911 through 1925 transitions<br>
> > - Sierra Leone: several 1913 through 1941 transitions, and DST<br>
> > was NOT observed in 1957 through 1962<br>
> > (Thanks to P Chan, Michael Deckers, Alexander Krivenyshev and<br>
> > Alois Treindl.)<br>
> ><br>
> > Merge more location-based Zones whose timestamps agree since 1970,<br>
> > as pre-1970 timestamps are out of scope. This is part of a<br>
> > process that has been ongoing since 2013. This does not affect<br>
> > post-1970 timestamps, and timezone historians who build with 'make<br>
> > PACKRATDATA=backzone' should see no changes to pre-1970 timestamps.<br>
> > When merging, keep the most-populous location's data, and move<br>
> > data for other locations to 'backzone' with a backward<br>
> > link in 'backward'. For example, move America/Creston data to<br>
> > 'backzone' with a link in 'backward' from America/Phoenix because<br>
> > the two timezones' timestamps agree since 1970; this change<br>
> > affects some pre-1968 timestamps in America/Creston because<br>
> > Creston and Phoenix disagreed before 1968. The affected Zones<br>
> > are Africa/Accra, America/Atikokan, America/Blanc-Sablon,<br>
> > America/Creston, America/Curacao, America/Nassau,<br>
> > America/Port_of_Spain, Antarctica/DumontDUrville, and<br>
> > Antarctica/Syowa.<br>
> ><br>
> > Changes to maintenance procedure<br>
> ><br>
> > The new file SECURITY covers how to report security-related bugs.<br>
> ><br>
> > Several backward-compatibility links have been moved to the<br>
> > 'backward' file. These links, which range from Africa/Addis_Ababa<br>
> > to Pacific/Saipan, are only for compatibility with now-obsolete<br>
> > guidelines suggesting an entry for every ISO 3166 code.<br>
> > The intercontinental convenience links Asia/Istanbul and<br>
> > Europe/Nicosia have also been moved to 'backward'.<br>
> ><br>
> > Changes to code<br>
> ><br>
> > zic now creates each output file or link atomically,<br>
> > possibly by creating a temporary file and then renaming it.<br>
> > This avoids races where a TZ setting would temporarily stop<br>
> > working while zic was installing a replacement file or link.<br>
> ><br>
> > zic -L no longer omits the POSIX TZ string in its output.<br>
> > Starting with 2020a, zic -L truncated its output according to the<br>
> > "Expires" directive or "#expires" comment in the leapseconds file.<br>
> > The resulting TZif files omitted daylight saving transitions after<br>
> > the leap second table expired, which led to far less-accurate<br>
> > predictions of times after the expiry. Although future timestamps<br>
> > cannot be converted accurately in the presence of leap seconds, it<br>
> > is more accurate to convert near-future timestamps with a few<br>
> > seconds error than with an hour error, so zic -L no longer<br>
> > truncates output in this way.<br>
> ><br>
> > Instead, when zic -L is given the "Expires" directive, it now<br>
> > outputs the expiration by appending a no-change entry to the leap<br>
> > second table. Although this should work well with most TZif<br>
> > readers, it does not conform to Internet RFC 8536 and some pickier<br>
> > clients (including tzdb 2017c through 2021a) reject it, so<br>
> > "Expires" directives are currently disabled by default. To enable<br>
> > them, set the EXPIRES_LINE Makefile variable. If a TZif file uses<br>
> > this new feature it is marked with a new TZif version number 4,<br>
> > a format intended to be documented in a successor to RFC 8536.<br>
> ><br>
> > zic -L LEAPFILE -r @LO no longer generates an invalid TZif file<br>
> > that omits leap second information for the range LO..B when LO<br>
> > falls between two leap seconds A and B. Instead, it generates a<br>
> > TZif version 4 file that represents the previously-missing<br>
> > information.<br>
> ><br>
> > The TZif reader now allows the leap second table to begin with a<br>
> > correction other than -1 or +1, and to contain adjacent<br>
> > transitions with equal corrections. This supports TZif version 4.<br>
> ><br>
> > The TZif reader now lets leap seconds occur less than 28 days<br>
> > apart. This supports possible future TZif extensions.<br>
> ><br>
> > Fix bug that caused 'localtime' etc. to crash when TZ was<br>
> > set to a all-year DST string like "EST5EDT4,0/0,J365/25" that does<br>
> > not conform to POSIX but does conform to Internet RFC 8536.<br>
> ><br>
> > Fix another bug that caused 'localtime' etc. to crash when TZ was<br>
> > set to a POSIX-conforming but unusual TZ string like<br>
> > "EST5EDT4,0/0,J365/0", where almost all the year is DST.<br>
> ><br>
> > Fix yet another bug that caused 'localtime' etc. to mishandle slim<br>
> > TZif files containing leap seconds after the last explicit<br>
> > transition in the table, or when handling far-future timestamps<br>
> > in slim TZif files lacking leap seconds.<br>
> ><br>
> > Fix localtime misbehavior involving positive leap seconds.<br>
> > This change affects only behavior for "right" system time,<br>
> > which contains leap seconds, and only if the UT offset is<br>
> > not a multiple of 60 seconds when a positive leap second occurs.<br>
> > (No such timezone exists in tzdb, luckily.) Without the fix,<br>
> > the timestamp was ambiguous during a positive leap second.<br>
> > With the fix, any seconds occurring after a positive leap second<br>
> > and within the same localtime minute are counted through 60, not<br>
> > through 59; their UT offset (tm_gmtoff) is the same as before.<br>
> > Here is how the fix affects timestamps in a timezone with UT<br>
> > offset +01:23:45 (5025 seconds) and with a positive leap second at<br>
> > 1972-06-30 23:59:60 UTC (78796800):<br>
> ><br>
> > time_t without the fix with the fix<br>
> > 78796800 1972-07-01 01:23:45 1972-07-01 01:23:45 (leap second)<br>
> > 78796801 1972-07-01 01:23:45 1972-07-01 01:23:46<br>
> > ...<br>
> > 78796815 1972-07-01 01:23:59 1972-07-01 01:23:60<br>
> > 78796816 1972-07-01 01:24:00 1972-07-01 01:24:00<br>
> ><br>
> > Fix an unlikely bug that caused 'localtime' etc. to misbehave if<br>
> > civil time changes a few seconds before time_t wraps around, when<br>
> > leap seconds are enabled.<br>
> ><br>
> > Fix bug in zic -r; in some cases, the dummy time type after the<br>
> > last time transition disagreed with the TZ string, contrary to<br>
> > Internet RFC 8563 section 3.3.<br>
> ><br>
> > Fix a bug with 'zic -r @X' when X is a negative leap second that<br>
> > has a nonnegative correction. Without the fix, the output file<br>
> > was truncated so that X appeared to be a positive leap second.<br>
> > Fix a similar, even-less-likely bug when truncating at a positive<br>
> > leap second that has a nonpositive correction.<br>
> ><br>
> > zic -r now reports an error if given rolling leap seconds, as this<br>
> > usage has never generally worked and is evidently unused.<br>
> ><br>
> > zic now generates a POSIX-conforming TZ string for TZif files<br>
> > where all-year DST is predicted for the indefinite future.<br>
> > For example, for all-year Eastern Daylight Time, zic now generates<br>
> > "XXX3EDT4,0/0,J365/23" where it previously generated<br>
> > "EST5EDT,0/0,J365/25" or "". (Thanks to Michael Deckers for<br>
> > noting the possibility of POSIX conformance.)<br>
> ><br>
> > zic.c no longer requires sys/wait.h (thanks to spazmodius for<br>
> > noting it wasn't needed).<br>
> ><br>
> > When reading slim TZif files, zdump no longer mishandles leap<br>
> > seconds on the rare platforms where time_t counts leap seconds,<br>
> > fixing a bug introduced in 2014g.<br>
> ><br>
> > zdump -v now outputs timestamps at boundaries of what localtime<br>
> > and gmtime can represent, instead of the less-useful timestamps<br>
> > one day after the minimum and one day before the maximum.<br>
> > (Thanks to Arthur David Olson for prototype code, and to Manuela<br>
> > Friedrich for debugging help.)<br>
> ><br>
> > zdump's -c and -t options are now consistently inclusive for the<br>
> > lower time bound and exclusive for the upper. Formerly they were<br>
> > inconsistent. (Confusion noted by Martin Burnicki.)<br>
> ><br>
> > Changes to build procedure<br>
> ><br>
> > You can now compile with -DHAVE_MALLOC_ERRNO=0 to port to<br>
> > non-POSIX hosts where malloc doesn't set errno.<br>
> > (Problem reported by Jan Engelhardt.)<br>
> ><br>
> > Changes to documentation<br>
> ><br>
> > tzfile.5 better matches a draft successor to RFC 8536<br>
> > <<a href="https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/01/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/01/</a>>.<br>
> ><br>
> > Here are links to the release files:<br>
> ><br>
> > <a href="https://www.iana.org/time-zones/repository/releases/tzcode2021b.tar.gz" rel="noreferrer" target="_blank">https://www.iana.org/time-zones/repository/releases/tzcode2021b.tar.gz</a><br>
> > <a href="https://www.iana.org/time-zones/repository/releases/tzdata2021b.tar.gz" rel="noreferrer" target="_blank">https://www.iana.org/time-zones/repository/releases/tzdata2021b.tar.gz</a><br>
> > <a href="https://www.iana.org/time-zones/repository/releases/tzdb-2021b.tar.lz" rel="noreferrer" target="_blank">https://www.iana.org/time-zones/repository/releases/tzdb-2021b.tar.lz</a><br>
> ><br>
> > The following convenience links are also available, although they may<br>
> > point to the previous release until the relevant caches are refreshed:<br>
> ><br>
> > <a href="https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz" rel="noreferrer" target="_blank">https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz</a><br>
> > <a href="https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz" rel="noreferrer" target="_blank">https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz</a><br>
> > <a href="https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz" rel="noreferrer" target="_blank">https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz</a><br>
> ><br>
> > Links are also available via plain HTTP, and via FTP from<br>
> > <a href="ftp://ftp.iana.org/tz/releases" rel="noreferrer" target="_blank">ftp://ftp.iana.org/tz/releases</a> with the same basenames as above.<br>
> ><br>
> > Each release file has a GPG signature, which can be retrieved by<br>
> > appending ".asc" to the above URLs. Copies of these signatures are<br>
> > appended to this message.<br>
> ><br>
> > This release corresponds to commit<br>
> > 9ffa3f6e5019dfa7cfb5c0e4e8a84fa95adec704 dated 2021-09-24 16:23:00<br>
> > -0700 and tagged '2021b' in the development GitHub repository at<br>
> > <<a href="https://github.com/eggert/tz" rel="noreferrer" target="_blank">https://github.com/eggert/tz</a>>.<br>
> ><br>
> > Here are the SHA-512 checksums for the release files:<br>
> ><br>
> > 00fca7508cfbc42123065fe8087397c9dd2acbdda96f3bb0936187825348cf13538f1893f2d02bd8bfa3465427ca7a9a65451baffe39889bc58ba0a77a047806<br>
> > tzcode2021b.tar.gz<br>
> > ca61d64af5ae791f337533c09d2b4f7caa645ecab7b9d13e9bcafc47c7c68535abe7c103c56bbd41d6bd913a8607f9c5187c8ce8a91b4891a750a643f89c8b51<br>
> > tzdata2021b.tar.gz<br>
> > 326fb99666c8d5bb798a9c24d2869307620dce918d47fbedd7f765c91eb35ea44bf776f43cb00cde1944884150232ac6dcdc0194a0364e2d28f6470691cf9177<br>
> > tzdb-2021b.tar.lz<br>
> ><br>
> > Here are the GPG digital signatures for the release files:<br>
> ><br>
> > -----BEGIN PGP SIGNATURE-----<br>
> ><br>
> > iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFOX/wACgkQ7ZfpDmKq<br>
> > fjRKwA//RVH1mmf13Uz99KBQZMc/meVaYT1YSpMqilocZo1w+i+Omai7Aw/r9u1e<br>
> > lnwLQukqjpCH4TJWdq8VuloL5ojN1ImoZuIRYECWRHOShxMaS9DLkPRr4qA9Fxic<br>
> > hladneiIglVrnzQbG4pH0Vnu9Qakb6I+1um8lCNiJHng84y5KAOIcZu1m9O+A1F1<br>
> > bdik8Ddxc4qBluUvcq9n9aqWSgDBvIyCYik6bOo3lOd5zP1rcjSr8VJ+15cAkH4X<br>
> > hU/igj9qloyqAmoOyJOzIIwv63T3Xg63rH/V2hJWyux54ayP4Kt8nZqLYA9V8gFI<br>
> > V/HL5qNafSYEqguO2H3hTwURc3Utini8Oa2Ou89Ih0hkO+nySacc0ZnhaunmX7Ip<br>
> > D5Oj6A8kssG0Uj5fZqpqUp1FeRbziAinSdwTOpRxdkdeHI6tfS0XVnRvRiFATfTu<br>
> > oh9107e3okwKAb2UPJtr8Oev0uU8rz8+EorN9/PqJv0n2c3I69NUv6TudFVHM8uB<br>
> > lwG3hUNtWWYpK/rzwX8AQkwTrOHMN3VJ94T8xaTm13/jtk6R/+GgSjXKC2C9XZG6<br>
> > 5uvi6et06WnRVRO+V5TwnQdfY85pe5nqRDLeo0clxdkAvx6fslLpz9YNacLV/Gn8<br>
> > 0UIGt9CBKjE+PU1F5w+O/5btA/1aTojuSpKscdzgQIzXTfDlTZo=<br>
> > =+McC<br>
> > -----END PGP SIGNATURE-----<br>
> > -----BEGIN PGP SIGNATURE-----<br>
> ><br>
> > iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFOX/0ACgkQ7ZfpDmKq<br>
> > fjRYmg/9H3rMpV7uQdd+G2K0wybdzTH6vJiNQClWE1+wqCPh/L3e8kCbPIjSo7MF<br>
> > SFV/Pu4EDb9kjeA2ruEMYlLnpg5nTP7dYfFRsRDcQJ5Yw70luNImm1ipUkKr9o5Q<br>
> > oQqYFKzxvB0G1rE+/gMaxmCHtGaJnv0DEChhmAS5U4j48z71Fn3+UJIU9XPEaODD<br>
> > U1Fw62xDsxIlFKjZ9UvilhlVRMnnP5nK9hjrsFKn7OGbxYvkdaRoK5f3M+G5nGXh<br>
> > L9nZcE0cd/7zhD3+wlttcH+xw3b+5P+7sxMhucoWQXEl3KyIklh97fi7jzHBHz+s<br>
> > DRYLZv/yPoEp94QyCfaYdvWL/i4OX4/9YnXK3ruXDcEV2y8Zl7Wc70Ihxk3I2XAb<br>
> > S4YeMcb30uls93QUdSmuhpEEUWrS5e45OnPy9RnT/VnpCalxsukudSNRzuvivKZn<br>
> > TsPpf90VUtI9ncLZ4l7OoNVXSj5pJ6DS+V1nCesEQyfyFnFvgK/rogCZ0yt+Cosp<br>
> > zaXwBtGyOWwWsGgXHGdJoiQqt/FF8o387EL95vpFr9BRSdSQoKd6K9RrRIH9fuy/<br>
> > nnpaksD86fx+WbdLMtbHzsZgCqL1RTGO+kc35Qlr3vqH02UAZiwC9l3DHS9SA01c<br>
> > MGDy9zaiLsL/8/lUV3AP31dEP1+DY+BXvdFhIJkmIceBUf7zl0E=<br>
> > =PO3W<br>
> > -----END PGP SIGNATURE-----<br>
> > -----BEGIN PGP SIGNATURE-----<br>
> ><br>
> > iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFOX/4ACgkQ7ZfpDmKq<br>
> > fjSaPg//ZlKREhlxjnstpEl6W3x4sStpUrF/Kebp62txYoCjbK22EDnw4BbE0wFh<br>
> > BcIBGbfxioC2+1gAjG57LK0RzTqFPPuDA69qYIZFk+xLrREISDqrGHViLGkFEgm5<br>
> > jEDamuGW59UoBdnu4Klp1JAd7hvYQYEbbVaIVsrUlAL99OTyujeA6QoZdIjM43eh<br>
> > jx4g1P/XuHBqJEH7d9kOM5tBCRvgFhhcu/s4vOvrfFibRHRimYBuPlep5nJ88bb/<br>
> > UyCQ1oYIQucWtl+DOszICl/GTmuM33FMTeAX6OrlGxwON6KPI2qNzAaQVpK1apB/<br>
> > qF9dTnOVP8pygW6HkiFwNOKx4mplB2V8f1eqLT9mfdOQsEWPRuDyUvejBIr/Hmww<br>
> > jHF1w9TX8FxND2KQmcfZNTlKqYcw1O8Vz4m+0UnDzNuLiZAsnTBTrfnKMnVrTOFt<br>
> > 1K6KKK+v5y4WYu+pE36cIBM2YxITEpD+YrRr7G1ilzVgRH5FRGCJsxJu0O+BO35z<br>
> > rv9qVnJz0xISMJs+qSdJT8v4W4Uc6+crnHjAc7T7eAin3i3y/GY/MA44isCACmhx<br>
> > +Rq165laaHXnqTOgQfHhGjigJoH3JCnDYUwg6q+fMMBU2eALkOs+IbgdfVB3hoyo<br>
> > UOlYH/A25nuI0PrRgUKsN6N2lrfPjq3bM4twDw33BOyGJ/LN88w=<br>
> > =aNBd<br>
> > -----END PGP SIGNATURE-----<br>
> ><br>
> > PS. If your tzdata parser does not yet support negative DST offsets or<br>
> > times past 24:00, or if it insists on a 'pacificnew' file that is no<br>
> > longer present, this release's data entries can be turned into a<br>
> > rearguard-format tarball that should work even with these older<br>
> > parsers. This is intended to be a temporary transition aid for these<br>
> > parsers. To generate a rearguard-format tarball, obtain the full<br>
> > distribution as described above, and run the command 'make<br>
> > rearguard_tarballs' on a development host. Or you can run 'make<br>
> > rearguard.zi' to generate a single file that can be fed directly to a<br>
> > parser that works like 'zic'.<br>
</blockquote></div></div>