- tz - lists.iana.org

Permanent DST in Jordan
by Even Scharning Oct. 6, 2022

Oct. 6, 2022

The government of Jordan has decided to observe permanent daylight saving time according to this source: https://www.arabiaweather.com/en/content/a-government-decision-to-install-d… Even Scharning Time.is - exact time for any time zone https://time.is/

1 1

Re: [tz] New Yorker article on David Mills and NTP
by dpatte Oct. 5, 2022

Oct. 5, 2022

Thanks Michael. Its nice to see the draft. Of course this has been proposed before and no firm decision was made then. Whatever they decide, I see UTC is an unfortunate but fair compromise between SI standard length seconds, and keeping our digital clocks close to being in sync with the variable length seconds of UT1. ----- Original Message ----- From: Michael H Deckers [mailto:michael.h.deckers@googlemail.com] To: "dpatte" <dpatte(a)relativedata.com>, <tz(a)iana.org> Sent: Tue, 4 Oct 2022 20:15:25 +0000 Subject: Re: [tz] New Yorker article on David Mills and NTP On 2022-10-04 19:01, dpatte via tz wrote: > I follow numerous astronomy lists, and there is serious discussion at the IAU (International Astronomical Union) to get rid of leap seconds altogether, and possibly replace them by something else, perhaps leap minutes (or even leap hours) - making them far less common. I believe they expect to make a decision soon, though they have been discussing it for years and had planned to make a decision 2 or 3 years ago. The BIPM is now in charge, and the CGPM on 2022-11-15..18 in Paris will vote on the proposal D on pages 7..8 and 23..24 in [https://www.bipm.org/documents/20126/66742098/Draft-Resolutions-2022.pdf/2e…] Michael Deckers.

1 0

[PATCH] MEXICO Law Inititive: End of DST after 2022
by hdcg＠ier.unam.mx Oct. 4, 2022

Oct. 4, 2022

From: Aztec Eagle' Turbo <turbo(a)cie.unam.mx> http://sil.gobernacion.gob.mx/Archivos/Documentos/2022/09/asun_4385449_2022… Waiting for publishing in Diario Oficial de la Federación (DOF reference here when available) No new time zones created All border municipalities remain sync with US DST. All other zones remain same UTC offset, but no longer apply DST --- northamerica | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/northamerica b/northamerica index da84f354..7220905e 100644 --- a/northamerica +++ b/northamerica @@ -2616,6 +2616,14 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # 5- The islands, reefs and keys shall take their timezone from the # longitude they are located at. +# From <hdcg(a)ier.unam.mx>: End of DST 2022 Law Inititive +# http://sil.gobernacion.gob.mx/Archivos/Documentos/2022/09/asun_4385449_2022… +# Waiting for publishing in Diario Oficial de la Federación +# (DOF reference here when available) +# No new time zones created +# All border municipalities remain sync with US DST. +# All other zones remain same UTC offset, but no longer apply DST + # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Mexico 1931 only - May 1 23:00 1:00 D Rule Mexico 1931 only - Oct 1 0:00 0 S @@ -2631,8 +2639,8 @@ Rule Mexico 1996 2000 - Apr Sun>=1 2:00 1:00 D Rule Mexico 1996 2000 - Oct lastSun 2:00 0 S Rule Mexico 2001 only - May Sun>=1 2:00 1:00 D Rule Mexico 2001 only - Sep lastSun 2:00 0 S -Rule Mexico 2002 max - Apr Sun>=1 2:00 1:00 D -Rule Mexico 2002 max - Oct lastSun 2:00 0 S +Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D +Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S # Zone NAME STDOFF RULES FORMAT [UNTIL] # Quintana Roo; represented by Cancún Zone America/Cancun -5:47:04 - LMT 1922 Jan 1 6:00u -- 2.37.3

2 1

[PATCH] MEXICO Law Inititive: End of DST after 2022
by Aztec Eagle' Turbo Oct. 4, 2022

Oct. 4, 2022

http://sil.gobernacion.gob.mx/Archivos/Documentos/2022/09/asun_4385449_2022… Waiting for publishing in Diario Oficial de la Federación (DOF reference here when available) No new time zones created All border municipalities remain sync with US DST. All other zones remain same UTC offset, but no longer apply DST --- northamerica | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/northamerica b/northamerica index da84f354..7220905e 100644 --- a/northamerica +++ b/northamerica @@ -2616,6 +2616,14 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # 5- The islands, reefs and keys shall take their timezone from the # longitude they are located at. +# From <hdcg(a)ier.unam.mx>: End of DST 2022 Law Inititive +# http://sil.gobernacion.gob.mx/Archivos/Documentos/2022/09/asun_4385449_2022… +# Waiting for publishing in Diario Oficial de la Federación +# (DOF reference here when available) +# No new time zones created +# All border municipalities remain sync with US DST. +# All other zones remain same UTC offset, but no longer apply DST + # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Mexico 1931 only - May 1 23:00 1:00 D Rule Mexico 1931 only - Oct 1 0:00 0 S @@ -2631,8 +2639,8 @@ Rule Mexico 1996 2000 - Apr Sun>=1 2:00 1:00 D Rule Mexico 1996 2000 - Oct lastSun 2:00 0 S Rule Mexico 2001 only - May Sun>=1 2:00 1:00 D Rule Mexico 2001 only - Sep lastSun 2:00 0 S -Rule Mexico 2002 max - Apr Sun>=1 2:00 1:00 D -Rule Mexico 2002 max - Oct lastSun 2:00 0 S +Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D +Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S # Zone NAME STDOFF RULES FORMAT [UNTIL] # Quintana Roo; represented by Cancún Zone America/Cancun -5:47:04 - LMT 1922 Jan 1 6:00u -- 2.37.3

1 0

[PROPOSED] Treat 1931 changes in Mexico as DST
by Paul Eggert Sept. 30, 2022

Sept. 30, 2022

Mexico’s Chamber of Deputies was supposed to vote today on legislation abolishing DST in most of Mexico. Although the vote was delayed due to Internet problems, news coverage of the non-event led me to review our sources for DST in Mexico, and I found that tzdb considered the transitions in 1931 to be two changes to standard time, whereas it is considered to be DST in today’s news coverage, as well as in our main source, the history of Mexican local time published by the Investigation and Analysis Service of the Mexican Library of Congress. Fix this by considering the 1931 changes to be DST, not standard time. * NEWS: Mention this. * northamerica (Mexico): Add DST rules for 1931. (America/Mexico_City, America/Ojinaga, America/Chihuahua) (America/Hermosillo, America/Mazatlan, America/Bahia_Banderas): Use them. --- NEWS | 9 +++++++++ northamerica | 26 ++++++++------------------ 2 files changed, 17 insertions(+), 18 deletions(-) diff --git a/NEWS b/NEWS index 64327d0..bcdad41 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,14 @@ News for the tz database +Unreleased, experimental changes + + Changes to past time zone abbreviations and DST flags + + The temporary advancement of clocks in central Mexico in summer + 1931 is now treated as daylight saving time, instead of as two + changes to standard time. + + Release 2022d - 2022-09-23 12:02:57 -0700 Briefly: diff --git a/northamerica b/northamerica index 13fb064..f848228 100644 --- a/northamerica +++ b/northamerica @@ -2617,6 +2617,8 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # longitude they are located at. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S +Rule Mexico 1931 only - May 1 23:00 1:00 D +Rule Mexico 1931 only - Oct 1 0:00 0 S Rule Mexico 1939 only - Feb 5 0:00 1:00 D Rule Mexico 1939 only - Jun 25 0:00 0 S Rule Mexico 1940 only - Dec 9 0:00 1:00 D @@ -2667,9 +2669,7 @@ Zone America/Monterrey -6:41:16 - LMT 1921 Dec 31 23:18:44 Zone America/Mexico_City -6:36:36 - LMT 1922 Jan 1 0:23:24 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 Mexico C%sT 2001 Sep 30 2:00 -6:00 - CST 2002 Feb 20 -6:00 Mexico C%sT @@ -2680,9 +2680,7 @@ Zone America/Mexico_City -6:36:36 - LMT 1922 Jan 1 0:23:24 Zone America/Ojinaga -6:57:40 - LMT 1922 Jan 1 0:02:20 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1996 -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 @@ -2692,9 +2690,7 @@ Zone America/Ojinaga -6:57:40 - LMT 1922 Jan 1 0:02:20 Zone America/Chihuahua -7:04:20 - LMT 1921 Dec 31 23:55:40 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1996 -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 @@ -2703,9 +2699,7 @@ Zone America/Chihuahua -7:04:20 - LMT 1921 Dec 31 23:55:40 Zone America/Hermosillo -7:23:52 - LMT 1921 Dec 31 23:36:08 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1942 Apr 24 -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 @@ -2743,9 +2737,7 @@ Zone America/Hermosillo -7:23:52 - LMT 1921 Dec 31 23:36:08 Zone America/Mazatlan -7:05:40 - LMT 1921 Dec 31 23:54:20 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1942 Apr 24 -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 @@ -2755,9 +2747,7 @@ Zone America/Mazatlan -7:05:40 - LMT 1921 Dec 31 23:54:20 Zone America/Bahia_Banderas -7:01:00 - LMT 1921 Dec 31 23:59:00 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1942 Apr 24 -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 -- 2.37.3

2 2

Moving more zones to 'backzone'
by Paul Eggert Sept. 29, 2022

Sept. 29, 2022

Release 2021b moved to 'backzone' nine zones whose timestamps since 1970 were duplicates of other zones, as part of a process that started in 2013 in the interests of removing prior inequities, one step at a time. If we were to continue this process in the same way, we could install the attached proposed patch which would move more zones, chosen via the same procedure used for 2021b. It strikes me, though, now that Stephen Colebourne has established a mechanism that can let downstream users keep the duplicate-since-1970 zones, that it may be a more effective use of our time to move the rest of the duplicate-si ce-1970 zones now, while no urgent changes are pending. This would move another twelve zones if I've counted correctly, and would let us more efficiently turn our attention to other issues. Comments welcome.

18 50

Re: [tz] Direct implementation of mktime_z
by Ted Phelps Sept. 28, 2022

Sept. 28, 2022

Hi Tony, On 2022-09-24, Tony Finch wrote: > You might also like https://dotat.at/@/2008-09-10-counting-the-days.html > (That does things the hard way, rather than relying on tm_yday) > and https://dotat.at/@/2008-09-15-the-date-of-the-count.html Wow, that's some clever math you've done there; far nicer than the clumsy approach I'd used to canonicalize the year, month and day. It's a little slower than my clumsy approach in the case where the year, month and day are already in canonical form, but can be much faster when they're not. I'll incorporate those changes into my git project in the coming days, thank you! -Ted

4 7

[news] DOT to map out nation’s time zones after report shows no official map exists
by Tony Finch Sept. 27, 2022

Sept. 27, 2022

https://edition.cnn.com/2022/09/22/politics/time-zone-map-transportation-de… : Federal transportation officials are now at work creating an accurate : map of the nation’s time zones, according to a report by the inspector : general for the Department of Transportation. : : The issue came up, the inspector general’s office said, after the US : Senate passed legislation this year to end the biannual time turn by : making Daylight Saving Time permanent. : : Investigators found no single map accurately showing the boundaries : nationwide and said several sources of time information on the DOT : website contained errors, such as inaccurately noting the time practices : in some localities. For example, one map incorrectly identifies a : deviation in Nevada: “Elko County, NV is shown as the location that : changed time zones rather than the correct location, the city of West : Wendover.” : : “The official boundaries are narratively described [in federal : regulations] with various types of coordinates and geographic features : such as lines of longitude, State or county lines, and rivers,” the : report stated. -- Tony Finch <dot(a)dotat.at> https://dotat.at/ Sole: Northwest 5 to 7, occasionally gale 8 until later. Rough or very rough. Rain or showers. Good, occasionally poor.

1 0

Direct implementation of mktime_z
by Ted Phelps Sept. 24, 2022

Sept. 24, 2022

Hi folks, I'm not sure if this is of interest here or not, but... I recently found myself needing to be able to convert a timestamp to broken-down time in multiple different time zones in a multi-threaded program. My plan was to use the localtime_rz and mktime_z functions included in the tzcode distribution, but I found that while localtime_rz is slightly faster than glibc's localtime_r, mktime_z is substantially slower than mktime. Poking around in the code, I was a bit surprised to find mktime_z just does a binary search of the whole time_t range, though I did appreciate this comment: Adapted from code provided by Robert Elz, who writes: The "best" way to do mktime I think is based on an idea of Bob Kridle's (so its said...) from a long time ago. does a binary search of the time_t space. Since time_t's are just 32 bits, its a max of 32 iterations (even at 64 bits it would still be very reasonable). I ended up writing my own localtime_rz and mktime_z with the assumption that time_t is always 64-bits and neither would ever be used with leap seconds (which was fine for the problem at hand) but that got me thinking: how hard would it be to extend that to support leap seconds. I ended up getting something that appears to work; you can see the results here: https://github.com/tphelps/tz64/ The performance improvement is substantial; on my laptop (Intel i7-8550U, 4GHz) it takes about 35ns to convert a struct tm to a time_t; whereas mktime_z takes about 3,300ns. Which, finally, brings me to my question: is there any interest in reworking tzcode's mktime to use a more efficient algorithm? I realize that it's a reference implementation, so correctness is very important, and you folks might not want to make such a significant change. If, however, you are interested, perhaps we can review what I've done to find and address any shortcomings in the approach I've taken (or to decide that it's fatally flawed, of course) before trying to use them in localtime.c. Any thoughts? -Ted

3 6

[tz-announce] 2022d release of tz code and data available
by Paul Eggert via tz-announce Sept. 24, 2022

Sept. 24, 2022

The 2022d release of the tz code and data is available. This release reflects the following changes: Briefly: Palestine transitions are now Saturdays at 02:00. Simplify three Ukraine zones into one. Changes to future timestamps Palestine now springs forward and falls back at 02:00 on the first Saturday on or after March 24 and October 24, respectively. This means 2022 falls back 10-29 at 02:00, not 10-28 at 01:00. (Thanks to Heba Hamad.) Changes to past timestamps Simplify three Ukraine zones to one, since the post-1970 differences seem to have been imaginary. Move Europe/Uzhgorod and Europe/Zaporozhye to 'backzone'; backward-compatibility links still work, albeit with different timestamps before October 1991. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022d.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 0fc8f915a527d1d6610b9545aa3958cf89511927 dated 2022-09-23 12:02:57 -0700 and tagged '2022d' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 54491ef8dbab7c41754eb3f2990b8ccb2a10960098c7d78d94375d7f1362540f0d71ba77a46bcaf95f419f8d01a23bdf940cdc9c7906c23ad6c40cd1c788b1c2 tzcode2022d.tar.gz f0d9f1dc6b7613598a861a3860f249e5beff75d8c4bb12bae21018ee617044cf25065dff08f81b0e6ed2c43602f2166dd6407a989a369a004e068260f2eece30 tzdata2022d.tar.gz bb1873550d5bb3fb0d1b595f321e2e90e63bba11bbd80a8c3d440903cb7a9ecd1db58644751b0925bc2854c2b17107238b3a2b9d5f8f91188e3b80b0b67f2673 tzdb-2022d.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmMuBjEACgkQ7ZfpDmKq fjQAEg//W+Dm8r7XHCZXNi/H87476tS4AZ8LiggRU+SAnkm7JDj7rAHhpR5uAO1s e1wXaKSMsfxHtUHCjmDn9qguGA3OPUaySaIw6+BGplfCAXarBj5tCrwsiF6T0tvY z3gTeu2E1DDzz2vree0y3boX9aTuFGmc9Ru+dUOVR/O4dun5RbN4VvKBdVRBIOpJ nXVSB12ZRRuTRoXeoSmKfXNPocM330yquWu/HvEdoWSspnx1hptY53DmG+BrSwvS 4uGfqTs5D4zleOaFXLNFb2igwmTS7g2nJGusud7ClXNeU8PkBUiS8ptFTX2n+TnQ SQxuVh+hTlMUjOMFWAkWxDPPRMM4sH3IgRj3y8sgSVOEaCfP9CGH0AgrgH6UuTlQ RtlQeFW2iYSyzmnvatEoE4tGu0bPjnJD7cnMFj6JWdJmks/A8ZgkkOCSAQ9tnqRj pMih15BOeRiQD6JSf8UJ7CIVhe44pN52DKIVZUxFzd6wyj25QRzF7yARykXYUAb6 quwy/WqkLV56MuZ21BuSWPXra1VXXygDctYHPSUuoXdHPEqY5BYtDNXD77e2vPiM X3oLLFe1j4rlY1tWQOymAFWJXL580l+kgzCS8Hf2cbPC0/on4Juol4rY4EB3RZHc FxhWPNDu9E1IIS4BP0BRLG56PQ9sGCy9NUFyxcimWBG2ApXHPTA= =MG7s -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmMuBkQACgkQ7ZfpDmKq fjQPuQ/9HOGp0hSxUup5vWDn0Eb5LChS+5J3nP1e6f6hjghGtOotMEmg/4Fc0w1w HqdEniaTzxMa//UxArnHrUP+rXNiodUIiykHXWXxGcEuYF3VX/PtFfBtodLRszRS gTbzRABrlzuyEvecX1/0rU+msi4IHAFV+/YFMv+2C5Fp8ra/nkailbN667m1MG6y HmHLov/lOfuZNKWGa1Z6B/gr7Oh3LmeQ+sPJc0v4OvKmPEER6E+Zwc4DvMJechD4 IJmdwkfHngyjgDHI2my8lvxWkWQnYgC2WXM/tZ/FAMSErakpwnpUo0FbzLs4Dfy1 WERS59Xqi8tiA+7hLxMGPirnXAF21hyb+L2E96FOVDv/ebQrwkfdekGN6MNYPLpy +pCbfwC+0zcfPc9BbvyxxPwdmpvzsFBQ3VwFO/M0jJQ8K6S/5OkTOi5OuKYaKVhV Wb6cXDE1Mf4EctOW/lyuA+xxJLRadjqFg6Cc5brFKLm7bf05JevGi/oboVo8sXIh qdYc8kqEEBdOzymeSwuo71jNaAYK2hN4hsDaJfxHQdObRx2p53AMTu+99pYiYHiT jOEXBQv6HwA4ve1oz2iMqsS2WTNfLctIVxYsFOLDXVHBkgxm5J9FQqJRvoDc30PK eYNRahWQ3MBGtaDRHQU5Vhru+au5CywihGTDvItvLpgVAO5LwJs= =VLZ9 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmMuBkgACgkQ7ZfpDmKq fjSHIxAAplxEGo1Sl94i7OXjVBJameXZ3p2J5AQ7LN3P1N8BOYiCPDaQzfjXprix Ev9Rm+FUOBx0ZDvm03av0MvH1b2sWhFp3VtxcKFiTpyGCRBOPgSG7IsKiLndlcgh eFFc1IOXWPdm9nTma9XxOI0y2oAl8xdK6F43cULpBslkjPyB5diBu/emI28sJ5Jo d8rgCH9mrvBKPCOgOC56T3rSsCXU71lon49l44tjfBw9FcQRgdB4GRnBKpJYPMqb QUZT6WI6sbRqWrKyVxNC8zks4n1zq0eFhFXSlXFHKUicR63h/PoCEzWX3v2yxZc2 gAFq9cb2Ivab/wz4l1khot9PZBdvYSe4fzcbmNG97fmqkLEg3Lw2ZuqEZBYv3WLn yGnPmDQGwvLwNe28nrAJwmZDccC348XQ8mO8wc5FOk+pWmSx0mW/trgDADTdgK89 pgN9chj3OjC1yagMG8DZWu6LoV+jOdrqI/hRAE9ws/z3iizfebadNYVzN8dLt4xk 7bcKUQ9oddA/kHBtDg28LCEd/3yodVocRpltP2JJgbDdJd8KjrGdBlp/VGbIOCpi KM3N8IXZPVfO/7oUGhFYWCskVLgWQSvwpBXI2+J3fFq3NYHlV20zXhaDeRDYLqxD wNUvDpPZZ8nTO5bhr5AYsW5fa7+tz/itQw/foju2/lp/Wh9XLL8= =sBcz -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. This is intended to be a temporary transition aid for these parsers. To generate a rearguard-format tarball, obtain the full distribution as described above, and run the command 'make DATAFORM=rearguard tailored_tarballs' on a development host. Or you can run 'make rearguard.zi' to generate a single file that can be fed directly to a parser that works like 'zic'.

1 0