- tz - lists.iana.org

[PROPOSED] Omit some no-longer-live packages
by Paul Eggert March 4, 2021

March 4, 2021

* tz-link.html: Remove pointers to some software packages that no longer seem live: ZoneInfo.Java, Time Zone Master, VelaTerra. --- tz-link.html | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/tz-link.html b/tz-link.html index af8885f..e7570a2 100644 --- a/tz-link.html +++ b/tz-link.html @@ -580,9 +580,6 @@ the Apache License.</li> library that translates between <abbr>UT</abbr> and civil time and can read <abbr>TZif</abbr> files. It is freely available under the Apache License.</li> -<li><a href="http://bmsi.com/java/#TZ">ZoneInfo.java</a> -is a <abbr>TZif</abbr> file reader written in Java. -It is freely available under the <abbr>LGPL</abbr>.</li> <li><a href="https://github.com/derickr/timelib">Timelib</a> is a C library that reads <abbr>TZif</abbr> files and converts timestamps from one time zone or format to another. @@ -667,15 +664,6 @@ href="https://www.oracle.com/java/index.html">Oracle Java</a> contains a copy of a subset of a recent <code><abbr>tz</abbr></code> database in a Java-specific format.</li> -<li><a href="https://relativedata.com/page/Time-Zone-Master">Time Zone -Master</a> is a Microsoft Windows clock program that can automatically -download, compile and use <code><abbr>tz</abbr></code> releases. -The Basic version is free.</li> -<li><a -href="http://veladg.com/velaterra.html">VelaTerra</a> is -a macOS program. Its developers -<a href="http://veladg.com/tzoffer.html">offer free -licenses</a> to <code><abbr>tz</abbr></code> contributors.</li> </ul> </section> -- 2.27.0

1 0

Eighth Continent Zealandia/Te Riu-a-Maui
by Brian Inglis March 3, 2021

March 3, 2021

Australians appear to agree that New Zealand is situated on its own (largely submerged) continental crust, along with nearby island groups, so we may have to consider a future split: https://www.bbc.com/future/article/20210205-the-last-secrets-of-the-worlds-… https://www.gns.cri.nz/static/unclos/images/unclosbook_print.pdf https://en.wikipedia.org/wiki/Zealandia#Political_divisions -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

3 2

Some time zone history (3)
by P Chan March 3, 2021

March 3, 2021

Correction: > British Guiana/Guyana adopted GMT-4 on 1911-08-01, GMT-3:75 on 1915-03-01, GMT-3 on 1975-08-01 and GMT-4 on 1992-03-29. GMT-3:75 should be GMT-3:45 --------- Most of the documents below were obtained from British Online Archives and LLMC Digital. ---------- Barbados https://1drv.ms/u/s!AgX5Bc6Y-VsIi3ioucfhJMcNlHr_?e=wjYyQa Definition of Time Act, 1911 (1911-7) [1911-08-28] Defence (Daylight Saving) Regulations, 1942, 1942-04-13 Defence (Daylight Saving) (Repeal) Regulations, 1942, 1942-08-22 Defence (Daylight Saving) Regulations, 1943, 1943-04-16 Defence (Daylight Saving) (Repeal) Regulations, 1943, 1943-09-01 Defence (Daylight Saving) Regulations, 1944, 1944-03-21 Defence (Daylight Saving) (Repeal) Regulations, 1944, 1944-04-30 Standard time of GMT-4 was adopted in 1911. DST was observed in 1942-44. The transitions were: 1942-04-19 05:00 GMT 1942-08-31 06:00 GMT 1943-05-02 05:00 GMT 1943-09-05 06:00 GMT 1944-04-09 05:00 GMT 1944-09-10 06:00 GMT --------- Gambia https://1drv.ms/f/s!AgX5Bc6Y-VsIi0MbGvyuIXGge6Iq Interpretation Ordinance, 1914 (No. 12 of 1914) [1914-09-29] Interpretation Ordinance, 1933 (No. 10 of 1933) [1933-03-31] Notice No. 5 of 1942, Colony of the Gambia Government Gazette, Vol. LIX, No.2, 1942-01-15, p 2 Interpretation (Amendment) Ordinance, 1946 (No. 3 of 1946) [1946-07-15] Standard time of GMT-1 was adopted on 1933-04-01. On 1942-02-01, GMT was adopted as a war time measure. This was made permanent in 1946. --------- Malawi https://1drv.ms/f/s!AgX5Bc6Y-VsIi0sbGvyuIXGge6Iq Interpretation and General Clauses Ordinance, 1911 (No. 12 of 1911) [1911-07-24] Notice No. 124 of 1914, 1914-06-30, The Nyasaland Government Gazette, Vol. XXI, No. 8, 1914-06-30, p 122 Interpretation and General Clauses (Amendment) Ordinance, 1925 (No. 3 of 1925) [1925-04-02] In 1911, Zomba mean time was adopted as the legal time of Nysaland. In 1914, Zomba mean time switched from GMT+2:21:10 to GMT+2:21. On 1925-07-01, GMT+2 was adopted. ---------- Nigeria https://1drv.ms/f/s!AgX5Bc6Y-VsIi0cbGvyuIXGge6Iq Government notices for the transition in 1905 and 1908. Government Notice No. 427 of 1905, 1905-06-17, Government Gazette. Colony of Lagos, No. 32, 1905, 1905-06-21, p 395 Government Notice No. 742 of 1908, 1908-06-24, Government Gazette. Colony of Southern Nigeria, No. 44, Vol. 3, 1905-06-24, p 869 ---------- Sierra Leone https://1drv.ms/f/s!AgX5Bc6Y-VsIi1EbGvyuIXGge6Iq Government Notice No. 121 of 1913 , 1913-06-06, Sierra Leone Royal Gazette, Vol. XLIV, No. 1384, 1913-06-14, p 347 Alteration of Time Ordinance, 1932 (No. 34 of 1932) [1932-12-01] Alteration of Time (Amendment) Ordinance, 1938 (No. 25 of 1938) [1938-11-24] Defence Regulations (No. 9), 1939 (Regulations No. 9 of 1939),1939-09-05 Defence Regulations (No. 11), 1939 (Regulations No. 11 of 1939), 1939-09-27 Defence (Amendment) (No.17) Regulations, 1941 (Public Notice No.157 of 1941), 1914-12-04 Alteration of Time (Amendment) Ordinance, 1946 (No. 2 of 1946) [1946-02-07] Standard time of GMT-1 was adopted on 1913-07-01. Twenty minutes of DST was introduce in 1932 and was suspended in 1939. In 1941, GMT was adopted by Defence Regulations. This was made permanent in 1946. For DST in 1957-62, I have looked through the gazettes from 1957 to 1961 but could not find any laws or notices related to DST. Also, the Local Time Ordinance (Cap 2, 1960 Revised Edition) <https://books.google.com/books?id=B-U-AQAAIAAJ&pg=PA18> does not contain any provisions related to DST. Proposed Rules: # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule SL 1932 only - Dec 1 0:00 0:20 -0040 Rule SL 1933 1938 - Mar 31 24:00 0 -01 Rule SL 1933 1939 - Aug 31 24:00 0:20 -0040 Rule SL 1939 only - May 31 24:00 0 -01 Rule SL 1939 only - Sep 5 0:00 0 -01 Zone Africa/Freetown -0:53:00 - LMT 1882 -0:53:00 - FMT 1913 Jul 1 # Freetown Mean Time -1:00 SL %s 1941 Dec 6 24:00 0:00 - GMT

2 5

Re: [tz] tz Digest, Vol 114, Issue 4
by Alan Lehotsky March 2, 2021

March 2, 2021

I can confirm that there can be funny behavior on 32 bit O/S if zic runs without -b fat Sent from my iPhone > On Mar 2, 2021, at 10:08, tz-request(a)iana.org wrote: > > Send tz mailing list submissions to > tz(a)iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request(a)iana.org > > You can reach the person managing the list at > tz-owner(a)iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. Re: Troubles with zone Asia/Gaza after tzdata2020b release > (Evgheni Antropov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Mar 2021 08:49:33 +0000 > From: Evgheni Antropov <Evgheni.Antropov(a)addgrup.com> > To: Paul Eggert <eggert(a)cs.ucla.edu>, Tim Parenti > <tim(a)timtimeonline.com> > Cc: Time zone mailing list <tz(a)iana.org> > Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b > release > Message-ID: <5b8eea9809f34e658c6529708744c1ad(a)addgrup.com> > Content-Type: text/plain; charset="us-ascii" > > Dear Paul and Tim, > Thank you for attention to this issue. > > We're using tzdata on the our embedded devices with ARMv7 Processor rev 2 (v7l), which has vanilla kernel > [root@Router8:~]# uname -a > Linux Router8 4.4.19-gdb0b54cdad #49 PREEMPT Mon Sep 30 15:10:54 EEST 2019 armv7l GNU/Linux > > Whole filesystem was compiled using Yocto Project 1.5 (poky-dora-10.0.0) https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora > > Tzdata was compiling on Ubuntu 18.04 without any additional flags and cross-compilers, just simple make install > #!/bin/sh > make clean > > #For compiling source extract tzdata and tzcode in one directory and run: > make TOPDIR=$(pwd)/binaries install > > with additional changes related with requests from our several customers, which are not effecting on the this file. > > In attachment you can see whole listing of compilation. > > Best regards, > > > Evgheni Antropov > Software R&D Engineer > +373 22 404 665 > www.addgrup.com<http://www.addgrup.com> > > > -----Original Message----- > From: Paul Eggert <eggert(a)cs.ucla.edu> > Sent: Tuesday, March 2, 2021 01:59 > To: Tim Parenti <tim(a)timtimeonline.com> > Cc: Evgheni Antropov <Evgheni.Antropov(a)addgrup.com>; Time zone mailing list <tz(a)iana.org> > Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b release > >> On 3/1/21 1:19 PM, Tim Parenti via tz wrote: >> Why is the system you're >> testing only looking at the (legacy) 32-bit data in the v1 data block, >> and not using the 64-bit data in the v2+ data block? Please let us >> know more about the system you're running > > Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. > Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem. > > Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza. > >> Please let us know more >> about the system you're running > > Yes, that'd be helpful. >

1 0

zdump man page misleading?
by Martin Burnicki Feb. 26, 2021

Feb. 26, 2021

Hi, the zdump.8.txt file generated from the current github code says: -c [loyear,]hiyear ... Cutoffs are at the start of each year, where the lower-bound timestamp is *exclusive* and the upper is *inclusive*; for example, -c 1970,2070 selects transitions after 1970-01-01 00:00:00 UTC and on or before 2070-01-01 00:00:00 UTC. The default cutoff is -500,2500. and $ ./zdump -V -c 2021,2022 Europe/Berlin Europe/Berlin Sun Mar 28 00:59:59 2021 UT = Sun Mar 28 01:59:59 .. Europe/Berlin Sun Mar 28 01:00:00 2021 UT = Sun Mar 28 03:00:00 .. Europe/Berlin Sun Oct 31 00:59:59 2021 UT = Sun Oct 31 02:59:59 .. Europe/Berlin Sun Oct 31 01:00:00 2021 UT = Sun Oct 31 02:00:00 .. (lines shorted to avoid line-wrapping) So the lower year is *inclusive* and the upper year is *exclusive*, and from my understanding these words should be swapped in the text of the man page. Or am I missing something? If I'm correct, should I provide a patch or pull request for the git repo? Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki(a)meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy

3 3

time zones only ?
by William Karlsson Feb. 25, 2021

Feb. 25, 2021

Is there a simple way to compile only the timezones ? i.e. US/Central etc... No cities ? -- // Karlsson

3 2

New IANA-timezone support date/time library
by Kerry Shetline Feb. 24, 2021

Feb. 24, 2021

I’ve just finished an extensive update of a JavaScript/TypeScript date/time library that I’d previously used only for my own astronomy website, skyviewcafe.com <http://skyviewcafe.com/>. I’ve done enough updates to this library now that it may be of interest to many other software developers, especially if they want to handle the odd edge cases that exist in timezone handling, like 47-hour days and missing days and the like. One unique features is that it's possible for users to get live updates of the tz database, which usually don’t become available to applications without, at the very least, restarting an application, if not rebooting one’s computer. Libraries in this category are hardly unique, but one of the most popular libraries, Moment.js, is being phased out, so this seemed to be to be a good time to introduce a new one. Among the (possible) unique features, you can do things like find the specific moments of DST transitions and other transitions, like UTC offset changes, and get descriptions of these changes, like this: new DateTime('2021-11-07', 'America/New_York').getDiscontinuityDuringDay() → { start: '02:00:00', end: '01:00:00', delta: -3600000 } // fall back! // As soon as it’s midnight on the 30th, it’s instantly midnight on the 31st, erasing 24 hours:<br> new DateTime('2011-12-30', 'Pacific/Apia').getDiscontinuityDuringDay()) → { start: '00:00:00', end: '24:00:00', delta: 86400000 } // As soon as it’s midnight on the 31th, turn back to 1AM on the 30th, adding 23 hours to the day:<br> new DateTime('1969-09-30', 'Pacific/Kwajalein').getDiscontinuityDuringDay() → { start: '24:00:00', end: '01:00:00', delta: -82800000 } My updated library can be found here: https://www.npmjs.com/package/@tubular/time <https://www.npmjs.com/package/@tubular/time> Besides the IANA timezone support, this library also features the ability to handle variable switch-over from the Julian to the Gregorian calendar, which can be of helpful to those handling historical dates.

8 9

Re: [tz] Gratuitous optimization
by Paul Eggert Feb. 23, 2021

Feb. 23, 2021

Thanks, I installed your performance fix via the attached proposed patch. The performance bug seems to have been introduced by my commit 30364485a6fdc0333f48905db387e07abb70bac1 (2013-09-08) "Improve the support for perpetual DST" which first appeared in tzdb 2013e.

1 0

Re: [tz] New IANA-timezone support date/time library
by Kerry Shetline Feb. 23, 2021

Feb. 23, 2021

On 2021-02-22, at 14:25, Paul Gilmartin <PaulGBoulder(a)AIM.com> wrote: > But the "Help" link (<https://skyviewcafe.com/help/>) fails with 404. The “Help” link is working now, so I’m not sure what the issue was at the time you clicked on it. > I don't know whether you've followed the "Kiev"/"Kyiv" debate on tz(a)iana.org. > But I was curious what skyviewcafe.com does about it. I read a little of that, but haven’t followed it. At least the pronunciation of Kyiv isn’t an issue! ;) My geographic data base finds the Ukrainian capital by either spelling, so that’s not a problem. I’m not sure if showing “Europe/Kyiv” in my interface would be confusing or not, since that’s not the existing IANA name for the associated timezone. Users are generally expected to click “Find”, and find cities by name, thus getting longitude, latitude, and timezone automatically without fussing with a manual selection, so the IANA names aren’t quite so important. I also intend to update my manual interface to make timezone selections by standard UTC offset, and then a list of zones in that offset, as the default way to make a manual timezone selection, with region/zone being a secondary option. > I tried to enter > "50°25'N 30°31'E". I learned: > o It's tedious to enter such coordinates digit-by-digit. > o I found no way to refresh the page with the coordinates entered. It’s definitely tedious compared to just looking up a city and getting lat/long automatically. But if one wants to enter info manually, I’m curious what you’d prefer as a means of input. The manual entry field also supports rolling digits up and down, which is a fun way to explore how the sky changes as you change latitude and longitude. > Tz, trying to pivot away from the debate, says that internal directory > and filenames should not be obvious to users. Thus, applications should > not show me "America", "Denver", or "Kiev”. I hadn’t really thought of those names like “America/New_York” as file names, but as names for timezones as abstract timezone entities. In fact, there is no “America/New_York” file in the tzdb. There’s a file named “northamerica”, and inside that file, a zone entry named "America/New_York”. Perhaps that’s still something a bit too rawly technical to be considered user-friendly, however. -Kerrt

3 2

[PATCH 1/5] Don't cite Howse where no longer used
by Paul Eggert Feb. 23, 2021

Feb. 23, 2021

--- africa | 3 --- asia | 3 --- 2 files changed, 6 deletions(-) diff --git a/africa b/africa index 28168cf..fca9af7 100644 --- a/africa +++ b/africa @@ -30,9 +30,6 @@ # Milne J. Civil time. Geogr J. 1899 Feb;13(2):173-94. # https://www.jstor.org/stable/1774359 # -# A reliable and entertaining source about time zones is -# Derek Howse, Greenwich time and longitude, Philip Wilson Publishers (1997). -# # European-style abbreviations are commonly used along the Mediterranean. # For sub-Saharan Africa abbreviations were less standardized. # Previous editions of this database used WAT, CAT, SAT, and EAT diff --git a/asia b/asia index ed94413..ac7def8 100644 --- a/asia +++ b/asia @@ -34,9 +34,6 @@ # Byalokoz EL. New Counting of Time in Russia since July 1, 1919. # (See the 'europe' file for a fuller citation.) # -# A reliable and entertaining source about time zones is -# Derek Howse, Greenwich time and longitude, Philip Wilson Publishers (1997). -# # The following alphabetic abbreviations appear in these tables # (corrections are welcome): # std dst -- 2.27.0

2 6