April 2020 - tz - lists.iana.org

Italy April 1944 discrepancy between comment and data
by Alois Treindl Oct. 5, 2021

Oct. 5, 2021

For Italy in 1944 zone Europe/Rome there is a discrepancy between the comment and the data. comment: # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. # Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. Data for Italy is Rule Italy 1944 only - Apr 2 2:00s 1:00 S Data for C-Eur is: Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S where Mon>=1 in 1944 is April 3. So Rome is NOT following C-Eur. I think the rule for Itay is right, only the comment is misleading.

4 9

Database available in other formats
by Sergio Bonfiglio May 3, 2020

May 3, 2020

Dear Sirs, First thig first a big THANK YOU for your invaluable work. I was overwhelmed by the complexity of your database, because it requires also external pieces of code to be safely read. I was wondering if does exist the database in different formats that may be larger but more readable and easy usable. An SQL database could be really "for everyone", because can be queried by everything from everywhere by any language. If I may make a humble suggestion, a JD date in floating format that equips any record with the initial and final date of the rule/event could be of great help. With a single query, one could recall all the records that pertain a certain moment in time also with different and overlapping rules. Thanks for any reply and thank for your work that is making me sweat the classical " seven shirts". Stay well Sergio Bonfiglio ITALY

2 6

[PROPOSED] Remove tzsetwall
by Paul Eggert April 24, 2020

April 24, 2020

Might as well do this now, while it’s fresh in my mind. * Makefile, NEWS: Update accordingly. * localtime.c (tzset_unlocked, tzsetlcl): Merge, since there’s now only one caller to either. * localtime.c, private.h (tzsetwall): Remove. --- Makefile | 3 +-- NEWS | 8 ++++++++ localtime.c | 20 ++------------------ private.h | 5 ----- 4 files changed, 11 insertions(+), 25 deletions(-) diff --git a/Makefile b/Makefile index 610bf19..107f67e 100644 --- a/Makefile +++ b/Makefile @@ -333,9 +333,8 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # add # -DSTD_INSPIRED # to the end of the "CFLAGS=" line. This arranges for the functions -# "tzsetwall", "offtime", "timelocal", "timegm", "timeoff", +# "offtime", "timelocal", "timegm", "timeoff", # "posix2time", and "time2posix" to be added to the time conversion library. -# "tzsetwall" is deprecated and is intended to be removed soon; see NEWS. # "offtime" is like "gmtime" except that it accepts a second (long) argument # that gives an offset to add to the time_t when converting it. # "timelocal" is equivalent to "mktime". diff --git a/NEWS b/NEWS index 321e090..ac491e1 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,13 @@ News for the tz database +Unreleased, experimental changes + + Changes to code + + The undocumented and ineffective tzsetwall function has been + removed. + + Release 2020a - 2020-04-23 16:03:47 -0700 Briefly: diff --git a/localtime.c b/localtime.c index 6623eac..d3e406b 100644 --- a/localtime.c +++ b/localtime.c @@ -1355,8 +1355,9 @@ zoneinit(struct state *sp, char const *name) } static void -tzsetlcl(char const *name) +tzset_unlocked(void) { + char const *name = getenv("TZ"); struct state *sp = lclptr; int lcl = name ? strlen(name) < sizeof lcl_TZname : -1; if (lcl < 0 @@ -1377,23 +1378,6 @@ tzsetlcl(char const *name) lcl_is_set = lcl; } -#ifdef STD_INSPIRED -void -tzsetwall(void) -{ - if (lock() != 0) - return; - tzsetlcl(NULL); - unlock(); -} -#endif - -static void -tzset_unlocked(void) -{ - tzsetlcl(getenv("TZ")); -} - void tzset(void) { diff --git a/private.h b/private.h index 8513663..9efcd78 100644 --- a/private.h +++ b/private.h @@ -477,8 +477,6 @@ typedef time_tz tz_time_t; # define tzfree tz_tzfree # undef tzset # define tzset tz_tzset -# undef tzsetwall -# define tzsetwall tz_tzsetwall # if HAVE_STRFTIME_L # undef strftime_l # define strftime_l tz_strftime_l @@ -551,9 +549,6 @@ extern long altzone; */ #ifdef STD_INSPIRED -# if TZ_TIME_T || !defined tzsetwall -void tzsetwall(void); -# endif # if TZ_TIME_T || !defined offtime struct tm *offtime(time_t const *, long); # endif -- 2.17.1

1 0

Re: [tz] [Bug 207345] zdump(8): zdump -c has an opposite behavior, in my xterm: lower bound is inclusive ...
by Paul Eggert April 24, 2020

April 24, 2020

I installed the attached doc patch to tzdb try to clarify things. The documented zdump behavior is kind of weird, but now's not the time to change it as we're about to do a new tzdb release.

2 1

Moroccan DST 2020 Change
by Ali ABDUL HAKEEM (Presta) April 24, 2020

April 24, 2020

Hello, Please note that the Moroccan government decided to activate DST between April 19th at 3am and may 31st at 2am. Hoping that you'll update the tzdata database soon. Regards, Ali Abdul Hakeem, OCM | IT Consultant | Tél: +212 520 475 306 Eurafric-Information | Département Système et bases de données [O_Database12c_Admin_Master_clr][OCM_ODb11gAdmin_clr][OCM_ODb10gAdmin_clr][OCP_MySQL5][RHCSA] [O_Certified Specialist_clr][CertWS_sm] [CertPowerSystems_sm]

2 3

'Australia/Canberra' time zone?
by John Pye April 24, 2020

April 24, 2020

Hi there I have been a bit surprised that the TZDATA database lacks a listing for "Australia/Canberra", population 350,000. What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion? Here is what I believe to be an official source about the Canberra timezone (at least for the present day): https://www.australia.gov.au/about-australia/facts-and-figures/time-zones-a… Cheers JP

8 19

[tz-announce] 2020a release of tz code and data available
by Paul Eggert April 23, 2020

April 23, 2020

The 2020a release of the tz code and data is available. It reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Briefly: Morocco springs forward on 2020-05-31, not 2020-05-24. Canada's Yukon advanced to -07 year-round on 2020-03-08. America/Nuuk renamed from America/Godthab. zic now supports expiration dates for leap second lists. Changes to future timestamps Morocco's second spring-forward transition in 2020 will be May 31, not May 24 as predicted earlier. (Thanks to Semlali Naoufal.) Adjust future-year predictions to use the first Sunday after the day after Ramadan, not the first Sunday after Ramadan. Canada's Yukon, represented by America/Whitehorse and America/Dawson, advanced to -07 year-round, beginning with its spring-forward transition on 2020-03-08, and will not fall back on 2020-11-01. Although a government press release calls this "permanent Pacific Daylight Saving Time", we prefer MST for consistency with nearby Dawson Creek, Creston, and Fort Nelson. (Thanks to Tim Parenti.) Changes to past timestamps Shanghai observed DST in 1919. (Thanks to Phake Nick.) Changes to timezone identifiers To reflect current usage in English better, America/Godthab has been renamed to America/Nuuk. A backwards-compatibility link remains for the old name. Changes to code localtime.c no longer mishandles timestamps after the last transition in a TZif file with leap seconds and with daylight saving time transitions projected into the indefinite future. For example, with TZ='America/Los_Angeles' with leap seconds, zdump formerly reported a DST transition on 2038-03-14 from 01:59:32.999... to 02:59:33 instead of the correct transition from 01:59:59.999... to 03:00:00. zic -L now supports an Expires line in the leapseconds file, and truncates the TZif output accordingly. This propagates leap second expiration information into the TZif file, and avoids the abovementioned localtime.c bug as well as similar bugs present in many client implementations. If no Expires line is present, zic -L instead truncates the TZif output based on the #expires comment present in leapseconds files distributed by tzdb 2018f and later; however, this usage is obsolescent. For now, the distributed leapseconds file has an Expires line that is commented out, so that the file can be fed to older versions of zic which ignore the commented-out line. Future tzdb distributions are planned to contain a leapseconds file with an Expires line. The configuration macros HAVE_TZNAME and USG_COMPAT should now be set to 1 if the system library supports the feature, and 2 if not. As before, these macros are nonzero if tzcode should support the feature, zero otherwise. The configuration macro ALTZONE now has the same values with the same meaning as HAVE_TZNAME and USG_COMPAT. The code's defense against CRLF in leap-seconds.list is now portable to POSIX awk. (Problem reported by Deborah Goldsmith.) Although the undocumented tzsetwall function is not changed in this release, it is now deprecated in preparation for removal in future releases. Due to POSIX requirements, tzsetwall has not worked for some time. Any code that uses it should instead use tzalloc(NULL) or, if portability trumps thread-safety, should unset the TZ environment variable. Changes to commentary The Îles-de-la-Madeleine and the Listuguj reserve are noted as following America/Halifax, and comments about Yukon's "south" and "north" have been corrected to say "east" and "west". (Thanks to Jeffery Nichols.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020a.tar.lz As usual, links to the latest release files are here: 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 7aec41a1d9b57c581af086db5de5bf99b165c405 dated 2020-04-23 16:03:47 -0700 and tagged '2020a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 5235d6590e844491df32375857f5f36ba0046f2d21a078375188dff79b125cf9b69136a0a431624de1ecfa9d53b62a232f0e6ee0b734294cec62b670e6265cb2 tzcode2020a.tar.gz 2a2fc2e3ad8a6e4c574242296c847ad582c2c1d86add9c556e65c812d19b9528522e3c4dddb5239017091825d2acc5a2ccaf21dc41b900b6c300ef4264cc5a9d tzdata2020a.tar.gz 6ef3ed39ee379adce421e7964ce9cf3d36361e2ba29de78e43b36d524c5722fd151c11ac60c952130d2623ecea9d8b56b4652f394e60a893a76d2ad769072d9d tzdb-2020a.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl6iH9IACgkQ7ZfpDmKq fjQK6BAAgxpJVrK35eNuGheX51np4f7mOAomDzMqXSaYZqYLW2EZCa+JW6VWfrEm eMZYVA/U33WsIGTjyyjfmq5FVwIQj0An+mAtlOR5dd34/ikGddZjd28ChrMW9+56 VFS7dA2pUjMzQp7yGG5sVek5OeGaHajfwxzBptPrsK+JwyNC1RcGetEcrgUwwznX S1iiLFvfzgVhrqnYzthIuoUikLSUkNumkr4/8frsYwywQ0axAzpkLi5rWxOfZAi6 a1MLMXvKmzXeiNCu5oeKl2XfTymBUVyF7K3dzFdkrOto8pSTDR+BbSh88mbe7tct Rt0q/GRq8fityECzdVAzoAqCRUU97t8V4VHNFXSxy32CN99cjsLdRMiVVEGTq+TT A3m9FjQidSCP3apzQe9JDfj536gQFSkUmDlcFwya31zolRoWkIFmxIhmZWIYlm9T Wjqc7y7UnrBNvyDE4pemQ4YYHjk5YLjwoaUIafDJTAiDRfcf53SRlr3tbFcYjAt/ Tql77DWuLmg8PGFtRiyCMqrehboGi0Eu3he2MmYtsJB2ZXFN0yZQmlvDen9fkt1k EqUkKjhHmVBb5WVS5pbl8mGLr1TFtnnedmLw4xULrDzsyJ5tsqzVnkl6Ga/eoIal lLIxpXrYqQLdHNtTpdmJkqZ/89++HDov9JR0uMzU8LxFwH6duQ4= =0y/R -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl6iH9MACgkQ7ZfpDmKq fjTb6g/+P/l6Nev5Zv8mUktnT6eNKohtgpNRyHd8nYV92wmTiDSzAArFy7oi5CVV /jMv8sbV1ssq/5rQ6HUQuMDPgEIO405gxmqRWMhE6UwUbRxxa+/HKGUJH0AHY6Dh 1UhVD7QA6fDovs84ip/WgTEZYcYApLr2A3IfC0rDqDo42DiSnErFQDvqRMJQkQS1 p2Pv7YtW/2NZ52wkfq75klSsjlXzlz6CzM5P3/YU/Hylj42sQdbdtbUAyQug3YpD QQ2PiZoP92iiGrcwkKXa5xvXJ6jEZCXqi7HbJKt8OW+XpZ/ZYbTZRq+JvMbTqkOL +XvVufo/pVASgv2V0ynzJu/XRiFUeJaecmEg6QiAiJ74UMTXSGFnK//R32M9dp29 B4p2X2jmW9qjCwjbjQXl1Yl5ddlSyvBk2Lk4s1repQ2t7kphZx2C8P2WyQYGeP7H nZDucfmWK4OSh8cINexBE8xyagmv1T8mC4qEQbVPva6JysaodNBcf9WkKMCgituP tbPsVekSmG1GyN2ixPtpY86Fzjr60mEg1UKqHZIagRmH4kjUwd1gINCJgONaZZxo c1VfBD8ZORBZfG27+V5ISotKrK2UrKtcrSUEU1CC/ibOm1sSPfg0d5uxUVvg4E8+ okdszbMnQ1i0eVKW+L+jY5XOO8kmSLp4YcnrqXDyZabxyWIGMt4= =7U2J -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl6iH9QACgkQ7ZfpDmKq fjTDQQ//S8WK8/aBHCKOiNvNFL82SHsrwSzsMt/5AyWzTUgkZZdhuhPmCu/qim0M J6Gm+1XUPaq6WKQnHbNk4wrmKjlRX/R1DWIA+2FhVH0iFSAX+qrnc/KUkm0hVXg4 u8aylAUOQvdhDfVX4PafCx21Kf1sk46oleRgi5lr3cSPAIKGsiEQKGR5EMbt/8mt 55zpxYGTj4o8yjY4NqEOBD8SHts0BO0xFq2eh6C71KeTeHKm/SasIFbvhIZug2cO YQyAnBiybfsSwIPXfYZr9ux81BztdzkzS6n1EBgGrHmk/+xrpBbmaknjFDMu+Nln qOPnTQCmp3NBXOYeVnxMAgIy07yEcAR7ReV0FuJFaxrkGYstfV6k5ylhk1iuHnIZ dOPSJa4eD+cIPWJTo0AsOkNx8+xJ6DkP8iudCpGUrEmXFSoMuFr8b5QwOxsRF/eC oIIRVO35gF12xr424DVKE72Z8yELoDGXzfWh8UbY/j0Lasq6RXqF9mrCMrugxlwx 1GofM2zrIkzkgLfMoV5zJfKrPiLPj213uGmrctJNcSggtSEA0DBvSvuhVe8hzolZ /taWc+/gCPBv159s3qedQyQbfHY0/IIkePdezwn4f7DQvh7MTOteE81AwJvqtkmQ fhSp+hz9k5m4CKuY9+71p+Srefc0i8PsBpmVCDYUn6PFqXaXsiA= =dCQ0 -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, this release's data entries can be turned into a rearguard-format tarball that does not use these features. 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 rearguard_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

Deprecating tzsetwall
by Paul Eggert April 22, 2020

April 22, 2020

In reviewing the tzdb web pages for bad links and suchlike, I noticed that they're still talking about UNIX SVR2 (superseded since 1988) and tzsetwall. So I looked into tzcode's implementation of tzsetwall, and noticed that it does nothing useful because functions like localtime now call tzset (as POSIX has require for many years), thus undoing tzsetwall's effect. Since nobody evidently cares whether tzsetwall works, we should remove it. Not right away of course, but we can document it as deprecated now without changing the implementation, and remove it in a future tzcode release. So I installed the attached patch to do that. Comments welcome as usual.

4 4

[PATCH] * tz-link.html: Update URLs.
by Paul Eggert April 21, 2020

April 21, 2020

--- tz-link.html | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/tz-link.html b/tz-link.html index 90cc9bd..1f893f6 100644 --- a/tz-link.html +++ b/tz-link.html @@ -82,11 +82,12 @@ title="Berkeley Software Distribution">BSD</abbr></a>, <a href="https://www.openbsd.org">Open<abbr>BSD</abbr></a>, <a href="https://www.chromium.org/chromium-os">Chromium OS</a>, <a href="https://cygwin.com">Cygwin</a>, +<a href="https://mariadb.org">MariaDB</a>, <a href="https://en.wikipedia.org/wiki/MINIX">MINIX</a>, <a href="https://www.mysql.com">MySQL</a>, <a href="https://en.wikipedia.org/wiki/WebOS"><abbr title="Web Operating System">webOS</abbr></a>, -<a href="https://ibm.com/aix"><abbr +<a href="https://en.wikipedia.org/wiki/IBM_AIX"><abbr title="Advanced Interactive eXecutive">AIX</abbr></a>, <a href="https://en.wikipedia.org/wiki/BlackBerry_10">BlackBerry 10</a>, <a href="https://www.apple.com/ios"><abbr @@ -168,7 +169,8 @@ then <samp>za</samp> through <samp>zz</samp>, then <samp>zza</samp> through <samp>zzz</samp>, and so on). Since version 2016h, each release has contained a text file named "<samp>version</samp>" whose first (and currently only) line is the version. -The releases are also available in an +Older releases are <a href="https://ftp.iana.org/tz/releases/">archived</a>, +and are also available in an <a href="ftp://ftp.iana.org/tz/releases/"><abbr title="File Transfer Protocol">FTP</abbr> directory</a> via a less-secure protocol.</p> @@ -827,10 +829,10 @@ zones and daylight saving time</a>.</dd> Chile's official time (in Spanish)</a>.</dd> <dt>China</dt> <dd>The Hong Kong Observatory maintains a -<a href="https://www.hko.gov.hk/gts/time/Summertime.htm">history of +<a href="https://www.hko.gov.hk/en/gts/time/Summertime.htm">history of summer time in Hong Kong</a>, and Macau's Meteorological and Geophysical Bureau maintains a <a -href="http://www.smg.gov.mo/smg/geophysics/e_t_Summer%20Time.htm">similar +href="https://www.smg.gov.mo/en/subpage/224/page/174">similar history for Macau</a>. Unfortunately the latter is incomplete and has errors.</dd> <dt>Czech Republic</dt> @@ -866,7 +868,7 @@ href="https://www.dia.govt.nz/Daylight-Saving-History">History of Daylight Saving</a>.</dd> <dt>Singapore</dt> <dd><a id="Singapore" -href="http://www.math.nus.edu.sg/~mathelmr/teaching/timezone.html">Why +href="https://web.archive.org/web/20190822231045/http://www.math.nus.edu.sg/~math…">Why is Singapore in the "Wrong" Time Zone?</a> details the history of legal time in Singapore and Malaysia.</dd> <dt>United Kingdom</dt> @@ -881,7 +883,7 @@ Time Zone Proceedings</a> lists changes to time zone boundaries.</dd> <dt>Uruguay</dt> <dd>The Oceanography, Hydrography, and Meteorology Service of the Uruguayan Navy (SOHMA) publishes an annual <a -href="http://www.armada.gub.uy/sohma/index.php/servicios/datos-astronomicos" hreflang="es">almanac +href="http://sohma.armada.mil.uy/index.php/servicios/datos-astronomicos" hreflang="es">almanac (in Spanish)</a>.</dd> </dl> </section> -- 2.17.1

1 0

Re: [tz] Errors in man pages, here: tzfile(5): Typo?
by Paul Eggert April 21, 2020

April 21, 2020

On 4/20/20 10:52 PM, Michael Kerrisk (man-pages) wrote: > --- a/man5/tzfile.5 > +++ b/man5/tzfile.5 > @@ -41,6 +41,7 @@ in order: > .TP > .I tzh_ttisgmtcnt > The number of UT/local indicators stored in the file. > +(UT is Universal Time.) Thanks. I looked for similar problems elsewhere and found one in zic.8, so I installed the attached patch. This should appear in the next tzdb release, which is due soon.

2 2

Data for China timezones in backzone
by Phake Nick April 15, 2020

April 15, 2020

First of all, for some reason there is a Vietnamese timezone which got sandwiched between time zone of China in the backzone file, I think that should be reordered for better clarity Second, the historical timezone data for those China zones seems to be incorrect. The transition to GMT+8 date given there for these zones were 1980 which also contradict the file description that they do not disagree with normal zone after 1970. According to sources that have also been cited in the asia file, except Xinjiang and Tibet, they should have adopted the Beijing Time from around 1949/1950 depends on exactly when each of those cities were taken over by the communist army. And they should also follow the DST setting of Asia/Shanghai after that point of time. In addition, http://gaz.ncl.edu.tw/detail.jsp?sysid=E1091792 the document from Chongqing Nationalist government say in year 1945 all of China should adopt summer time due to the war (not sure whether it continued after WWII ends)(Probably only enforced in area under their rule at the time?) The Asia/Harbin's 1932 and 1940 entry should also be incorrect. As per sources recorded at https://wiki.suikawiki.org/n/%E6%BA%80%E5%B7%9E%E5%9B%BD%E3%81%AE%E6%A8%99%… , in 1932 Harbin should have adopted UTC+8:00 instead of data currently listed in the tz database according to official announcement from Manchuko. And they should have adopted GMT+9 in 1937 January 1st according to official announcement at the time being cited on the webpage.

2 1

Asia/Shanghai timezone history and other information
by Phake Nick April 15, 2020

April 15, 2020

1. According to This news report: http://news.sina.com.cn/c/2004-09-01/19524201403.shtml , on April 11, 1919, newspaper in Shanghai said clocks in Shanghai will spring forward for an hour starting from midnight of that Saturday. The report did not mention what happened in Shanghai thereafter, but it mentioned that a similar trial in Tianjin which ended at October 1st as citizens are told to recede the clock on September 30 from 12:00pm to 11:00pm. The trial at Tianjin got terminated in 1920. 2. For the history of time in Shanghai between 1940-1942, the situation is actually slightly more complex than the table included in the tz database now. At the time, there were three different authorities in Shanghai, including Shanghai International Settlement, a settlement established by western countries with its own westernized form of government, Shanghai French Concession, similar to the international settlement but is controlled by French, and then the rest of the city of Shanghai, which have already been controlled by Japanese force through a puppet local government (Wang Jingwei regime) It was additionally complicated by the circumstances that, according to the 1940s Shanghai summer time essay cited in the database, some departments/businesses/people in the Shanghai city itself during that time period, refused to change their clock and instead only changed their opening hours. For example, as quoted in the article, in 1940, other than the authority itself, power, tram, bus companies, cinema, department stores, and other public service organizations have all decided to follow the summer time and spring forward the clock. On the other hand, the custom office refused to spring forward the clock because of worry on mechanical wear to the physical clock, postal office refused to spring forward because of disruption to business and log-keeping, although they did changed their office hour to match rest of the city. So is travel agents, and also weather observatory. It is said both time standards had their own supporters in the city at the time, those who prefer new time standard would have moved their clock while those who prefer the old time standard would keep their clock unchange, and there were different clocks that use different time standard in the city at the time for people who use different time standard to adjust their clock to their preferred time. 2.a. For the 1940 May 31 spring forward, the essay claim that it was coordinared between the international settlement authority and the French concession authority and have gathered support from Hong Kong and Xiamen, that it would spring forward an hour from May 31 "midnight", and the essay claim "Hong Kong government implemented the spring forward in the same time on the same date as Shanghai". 2.b. For the 1940 fall back, it was said that they initially intended to do so on September 30 00:59 at night, however they postponed it to October 12 after discussion with relevant parties. However schools restored to the original schedule ten days earlier. 2.c. For the 1941 spring forward, it is said to start from March 15 "following the previous year's method", and in addition to that the essay cited an announcement in 1941 from the Wang regime which said the Special City of Shanghai under Wang regime control will follow the DST rule set by the Settlements, irrespective of the original DST plan announced by the Wang regime for other area under its control(April 1 to September 30). (no idea to situation before that announcement) 2.d. For the 1941 fall back, it was said that the fall back would occurs at the end of September (A newspaper headline cited by the essay, published on October 1, 1941, have the headlines which said "French Concession would rewind to the old clock this morning), but it ultimately didn't happen due to disagreement between the international settlement authority and the French concession authority, and the fall back ultimately occurred on November 1. 2.e. In 1941 December, Japan have officially started war with the United States and the United Kingdom, and in Shanghai they have marched into the international settlement, taken over its control 2.f. For the 1942 spring forward, the essay said that the spring forward started on January 31. It said this time the custom office and postal department will also change their clocks, unlike before. 2.g. The essay itself didn't cover any specific changes thereafter until the end of the war, it quoted a November 1942 command from the government of the Wang regime, which claim the daylight saving time applies year round during the war. However, the essay ambiguously said the period is "February 1 to September 30", which I don't really understand what is the meaning of such period in the context of year round implementation here.. More researches might be needed to show exactly what happened during that period of time. 3. According to a Japanese tour bus pamphlet in Nanjing area believed to be from around year 1941: http://www.tt-museum.jp/tairiku_0280_nan1941.html , the schedule listed was in the format of Japanese time. Which indicate some use of the Japanese time (instead of syncing by DST) might have occurred in the Yangtze river delta area during that period of time although the scope of such use will need to be investigated to determine. ---- Other information: i. The HKO link reference link in Asia/HongKong have already become inaccessible probably due to site update. The link can now be accessed from https://www.hko.gov.hk/en/gts/time/Summertime.htm

2 1

Morocco : Time Change
by Semlali Naoufal April 15, 2020

April 15, 2020

Hello, Following the announcement by the Moroccan government, the switch to GMT time will take place on Sunday, April 19, 2020 from 3 a.m. and the return to GMT+ 1 time will take place on Sunday, May 31, 2020 at 2 a.m. and not Sunday May 24, 2020 as described at the TMZ base. To this end, thank you for updating the TMZ database to take this change into account. Attached the official decision of the government. https://maroc-diplomatique.net/maroc-le-retour-a-lheure-gmt-est-prevu-diman… http://aujourdhui.ma/actualite/gmt1-retour-a-lheure-normale-dimanche-procha… Best Regards, De : Tim Parenti <tim(a)timtimeonline.com<mailto:tim@timtimeonline.com>> Envoyé : lundi 30 septembre 2019 17:05 À : Naoufal Semlali <N.Semlali(a)iam.ma<mailto:N.Semlali@iam.ma>> Cc : Paul Eggert <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>>; Maamar Abdelkader <A.MAAMAR(a)iam.ma<mailto:A.MAAMAR@iam.ma>>; Time zone mailing list <tz(a)iana.org<mailto:tz@iana.org>> Objet : Re: [tz] Morocco Time must stay at GMT+1 We updated Morocco with year-round UTC+1 (except during Ramadan) about a year ago in these commits: https://github.com/eggert/tz/commit/80de44ca0f2349c0f42f12caa943ced8685c3b67 https://github.com/eggert/tz/commit/8539a448ebc8897e40d62f16dc4d0ada3f07b3ca If there are still errors in tz for Morocco in 2018g or later, please let us know. Otherwise, it sounds like you need to update your time zone definitions with a more recent version. -- Tim Parenti On Mon, 30 Sep 2019 at 11:40, Naoufal Semlali <N.Semlali(a)iam.ma<mailto:N.Semlali@iam.ma>> wrote: Good Morning, I want to inform you that Morocco is not concerned by the transition to the winter time which will take place in Europe on the night of Saturday, October 26 to Sunday, October 27, 2019. Morocco's schedule must stay on GMT+1 The schedule change take place only before and after the month of Ramadan. Best Regards De : Naoufal Semlali Envoyé : jeudi 18 avril 2019 08:27 À : 'Paul Eggert' <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>> Cc : Time zone mailing list <tz(a)iana.org<mailto:tz@iana.org>>; Maamar Abdelkader <A.MAAMAR(a)iam.ma<mailto:A.MAAMAR@iam.ma>> Objet : RE: Will Morocco switch from +01 to +00 during Ramadan next year? Hello, The predictions below seem to be correct based on the latest official declarations of the Moroccan government. Of course, if there will be any change, we will keep you informed. Thanks. Semlali -----Message d'origine----- De : Paul Eggert <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>> Envoyé : mercredi 17 avril 2019 19:04 À : Naoufal Semlali <N.Semlali(a)iam.ma<mailto:N.Semlali@iam.ma>> Cc : Time zone mailing list <tz(a)iana.org<mailto:tz@iana.org>>; Maamar Abdelkader <A.MAAMAR(a)iam.ma<mailto:A.MAAMAR@iam.ma>> Objet : Re: Will Morocco switch from +01 to +00 during Ramadan next year? On 4/17/19 12:24 AM, Naoufal Semlali wrote: > > Please confirm also that the switch to GMT+1 on Sunday, June 9th 2019 > at 2 am is already implemented in the tzdata. > Yes, I checked that too. For what it's worth, here are the tzdata 2018h-and-later predictions for Africa/Casablanca through the year 2037. The columns are the date, the hour just after the transition, the UTC offset just after the transition, and (optionally) 1 if (negative) DST is in effect. These predictions could well be wrong: if you have better info please let us know. 2019-05-05 02 +00 1 2019-06-09 03 +01 2020-04-19 02 +00 1 2020-05-24 03 +01 2021-04-11 02 +00 1 2021-05-16 03 +01 2022-03-27 02 +00 1 2022-05-08 03 +01 2023-03-19 02 +00 1 2023-04-23 03 +01 2024-03-10 02 +00 1 2024-04-14 03 +01 2025-02-23 02 +00 1 2025-04-06 03 +01 2026-02-15 02 +00 1 2026-03-22 03 +01 2027-02-07 02 +00 1 2027-03-14 03 +01 2028-01-23 02 +00 1 2028-02-27 03 +01 2029-01-14 02 +00 1 2029-02-18 03 +01 2029-12-30 02 +00 1 2030-02-10 03 +01 2030-12-22 02 +00 1 2031-01-26 03 +01 2031-12-14 02 +00 1 2032-01-18 03 +01 2032-11-28 02 +00 1 2033-01-09 03 +01 2033-11-20 02 +00 1 2033-12-25 03 +01 2034-11-05 02 +00 1 2034-12-17 03 +01 2035-10-28 02 +00 1 2035-12-02 03 +01 2036-10-19 02 +00 1 2036-11-23 03 +01 2037-10-04 02 +00 1 2037-11-15 03 +01 ________________________________ [Description : cid:image002.jpg@01CC9EE4.44A57D10]Eco – geste: privilégiez la sauvegarde électronique, si nécessaire imprimez en recto-verso ________________________________ Ce message et toutes les pièces jointes sont adressés à l'attention exclusive de leurs destinataires et sont strictement confidentiels. Si vous le recevez par erreur, merci de le détruire après en avoir informé l'expéditeur sans délai. Toute divulgation, copie ou usage par une personne autre que son destinataire sont interdits. Maroc Telecom décline toute responsabilité pour toute altération, déformation ou falsification subie par le message au cours de sa transmission. Retrouvez toutes les informations de Maroc Telecom sur www.iam.ma<http://www.iam.ma> . ________________________________ This message and its attachments are intended only for the person or entity to which it is addressed and are strictly confidential. If you have received this in error, please delete the material from any computer after having informed the sender. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited. Maroc Telecom accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about Maroc Telecom on www.iam.ma <http://www.iam.ma> .

2 2

Morocco Ramadan 2020
by Milamber April 14, 2020

April 14, 2020

Hello, The Government of Kingdom of Morocco have publish the changes of time for next Ramadan month (2020) [1] : Google Translation: The Ministry of Economy, Finance and Administration Reform - Department of Administration Reform - announces that on the holy month of Ramadan, the Kingdom of Morocco will return to legal time of the Kingdom (GMT) by delaying the time by 60 minutes and this on Sunday April 19 at 03:00 am In accordance with article II of the decree n ° 2.18.855 (October 26, 2018) relating to the legal time of the Kingdom, and to the decision of the Head of Government No. 3.25.20 (published on April 13, 2020) concerning the legal time. The Kingdom of Morocco will return to the schedule (GMT +1) by adding sixty (60) minutes to legal time on Sunday, May 31, 2020 at 2:00 a.m. Actually, the tzdata show (Debian 10) tzdata 2019c-0+deb10u1 : # zdump -v /usr/share/zoneinfo/Africa/Casablanca | grep 2020 /usr/share/zoneinfo/Africa/Casablanca Sun Apr 19 01:59:59 2020 UT = Sun Apr 19 02:59:59 2020 +01 isdst=0 gmtoff=3600 /usr/share/zoneinfo/Africa/Casablanca Sun Apr 19 02:00:00 2020 UT = Sun Apr 19 02:00:00 2020 +00 isdst=1 gmtoff=0 /usr/share/zoneinfo/Africa/Casablanca Sun May 24 01:59:59 2020 UT = Sun May 24 01:59:59 2020 +00 isdst=1 gmtoff=0 /usr/share/zoneinfo/Africa/Casablanca Sun May 24 02:00:00 2020 UT = Sun May 24 03:00:00 2020 +01 isdst=0 gmtoff=3600 thanks for update. Regards, Milamber * [1] https://www.mmsp.gov.ma/fr/actualites.aspx?id=1940

1 0

DST in Morocco
by Magnus Fromreide April 14, 2020

April 14, 2020

Hello. It seems as if Morocco have decided that Ramadan ends on 2020-05-31, not 2020-05-24 which is what was previously assumed. Source (in arabic): http://www.sgg.gov.ma/Portals/1/BO/2020/B.O_6873_Ar.pdf?ver=2020-04-14-1321… Especially page 2082 (page 4 of the document) /MF

1 0

DB incoherence
by Américo Mendes April 7, 2020

April 7, 2020

Hi, Was trying to use your DB and I found what I think it's a data incoherence... When you list the rules, i suppose that they must be in chronological order, I'm assuming that* (X) rule start date always smaller than (X+1) rule start date*, for instance: R Q 1967 o - Ap 8 0 1 D R Q 1967 1968 - S Su>=8 0 0 S R Q 1968 o - Ap 14 0 1 D R Q 1969 1977 - Ap lastSu 0 1 D R Q 1969 1971 - O lastSu 0 0 S R Q 1972 1974 - O 8 0 0 S R Q 1975 1977 - O lastSu 0 0 S I fund in the Haiti rules the following section: R HT 1983 o - May 8 0 1 D R HT 1984 1987 - Ap lastSu 0 1 D R HT 1983 1987 - O lastSu 0 0 S According to my assumption, to keep DB coherence, we should have, in 2nd position something like: R HT 1983 o - O lastSu 0 0 S Am I right or is it some particularity that I didn't understand? Best Regards. Américo Mendes <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Sem vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 2

Most of Mexico to spring forward tomorrow, as scheduled
by Paul Eggert April 4, 2020

April 4, 2020

Although most of Mexico is scheduled to spring forward tomorrow at 02:00, earlier this week Claudia Reyes Montiel, representing the caucus of the Mexican Party of the Democratic Revolution (PRD), asked Mexican president Andrés Manuel López Obrador (AMLO) to cancel or suspend DST in the light of the COVID-19 pandemic. AMLO has punted on this for now, saying that he first wants a technical opinion from the Ministry of Energy. One never knows with AMLO though, and it might be good to keep an eye out for sudden changes to Mexico's civil-time rules. My source: Horario de Verano 2020: Diputados del PRD le piden a AMLO eliminar el cambio. La Verdad. 2020-04-02. https://laverdadnoticias.com/politica/Horario-de-Verano-2020-Diputados-del-…

2 1

TZ Data Base Questions
by Dustin J. Dirth April 2, 2020

April 2, 2020

Hello, A group of developers including myself has been charged with dealing with time zones in our database. We have been looking into using the IANA TZ Database as our source. In order to create utilities to get historical data correctly, and to future proof our code as much as possible, there were a couple of questions we have been trying to find the answers to. * If an entity breaks off from a current time zone, does the data base fork the current time zone(A) and add a new time zone(B) with time zone B having all the historical data of A? * In the INANA time zone database, the file "europe" contains information for Time Zone Europe/Dublin. There are three lines that are proceeded with the comment "# These three lines are for when SAVE values are always nonnegative." These lines are also preceded by comment Delimiter (Please see below). Since the data follows the Comment Delimiter it is ignored on load. Is database supposed to load this information? What is the purpose of these comments? # These three lines are for when SAVE values are always nonnegative. # 1:00 - IST 1971 Oct 31 2:00u # 0:00 GB-Eire GMT/IST 1996 # 0:00 EU GMT/IST

5 6