- tz - lists.iana.org

Yukon, NWT, and Nunavut (Canada)
by Chris Walton Nov. 7, 2022

Nov. 7, 2022

There are some inaccuracies in the TZ database rules for Northern Canada between the years 1965 and 1995. ---------------------------------------------------------------------------------------- *Item A: On Sunday April 25, 1965, all parts of the Yukon switched to Yukon Double Daylight Time (YDDT). * This event is recorded in the database, but the associated rules have been incorrectly extended to cover almost all of Northern Canada. News article 1: *Whitehorse Star *—* Thursday April 22, 1965 *—* page 1* title: *DST Starts Monday* > > Yukon Daylight Saving Time starts this weekend. Clocks will be turned > ahead two hours after midnight Saturday, April 24 and there may be a lot of > people late for church this Sunday. > Trial period for DST was approved by Territorial Council last month for > this summer, after which a second look may be taken from Yukoners' point of > view. Two hour change was adopted to fall in line with British Columbia > and Alberta summer times. https://www.newspapers.com/image/578587481/ The title of this first article is wrong and/or misleading. Also, the start time shown in the article is vague; it simply says "after midnight" when it probably should have stated 2:00a.m. News article 2: *Whitehorse Star *—* Thursday April 29, 1965 *—* page 1* title: *DST Continues 'Till Hallowe'en* > Daylight Saving Time started in the Yukon five days ago, and already the > Commissioner's office is being besieged with calls from sleepy local > citizens wanting to know when it's going to end. > The two-hour change which began Sunday at two a.m. brings the Territory > into line with B.C. and Alberta time for the summer, but three hours ahead > for travelers from Alaska. > An official said Wednesday that many calls have come in from people asking > how long the experiment will last. The answer is another six months. > Date for the change back to Yukon Standard Time Oct. 31 at two a.m. https://www.newspapers.com/image/578588221/ News article 3: *Whitehorse Star *—* Monday October 25, 1965 *—* page 15* > Commissioner G.C. Cameron announced today that daylight Saving Time will > come to an end, for this year, at 2a.m. October 31. This means that all > clocks and watches should be turned back two hours as of that date. > The double daylight saving time was adopted this summer, on a trial basis > , so that Yukon time would correspondent with British Columbia and Alberta > time. > ... https://www.newspapers.com/image/578589147/ The 1965 Yukon Council minutes can be found here: http://assets.yukonarchives.ca/PER_YG_06_1965_C20_S02_v1.pdf Unfortunately I could not find an official CO or OIC. It is clear from the council minutes and the newspaper articles that the Yukon government wanted the clocks to be in sync with British Columbia and Alberta for the summer. However, the Yukon council members never once mentioned NWT (Northwest Territories) when debating or discussing the time change. I do not currently believe that NWT touched any of its clocks in 1965. Keep in mind that the land currently under the jurisdiction of Nunavut belonged to NWT prior to 1999. *All of the 1965 clock transitions for NWT and Nunavut should be removed from the TZ database unless somebody can provide compelling evidence to support them.* Zones in need of fixing: America/Yellowknife (NWT) America/Inuvik (NWT) America/Iqaluit (Nunavut) America/Cambridge_Bay (Nunavut) America/Pangnirtung (Nunavut) America/Rankin_Inlet (Nunavut) America/Resolute (Nunavut) *For the two Yukon zones, the April 25, 1965 start time should probably be changed in the TZ database from 00:00 to 2:00am.* Zones in need of fixing: America/Whitehorse America/Dawson ---------------------------------------------------------------------------------------- *Item B: On Sunday February 27, 1966, the part of the Yukon that lies east of the 136th meridian and south of the 62nd parallel switched from UTC-9 to UTC-8.* This change was mandated by Commissioner's Order 1966-20. Brian Inglis referenced it in a 2015 posting to this mailing list. https://mm.icann.org/pipermail/tz/2015-April/022200.html Brian was unable to locate a copy of the Commissioner's Order or any details about it. He simply stated "no online source found". I found two newspaper articles which give us the missing details: News article 1: *Whitehorse Star *—* Thursday Feb 24,1966 *—* page 2* title: *It's Time for YDT* > Sometime between midnight Saturday, Feb. 26 and Sunday morning Feb. 27, > residents of the southern part of the Yukon will get a bonus of an extra > hour for Rendezvous celebrating. > That's the date for changeover to Yukon Daylight Time which resulted from > the recent territorial plebiscite on the subject. > From Whitehorse to Watson Lake, settlements will observe the fast time; > elsewhere, Yukoners will remain on Yukon Standard Time. > Whitehorse, Ross River, Carcross, Teslin, Brooks Brook, Johnson's > Crossing, Watson Lake and Upper Liard... when the clock is wound at > midnight this Saturday, the hands should be set ahead one hour... to one > o'clock Yukon Daylight Time. https://www.newspapers.com/image/578575979/ I don't think that the author understood that moving the clock forward meant an hour was lost instead of gained! Oh well! Also, it was a permanent change and should not have been considered to be "daylight time". News article 2 (with more detail): *Whitehorse Star *—* Thursday March 3, 1966 *—* page 15* title: *Standard Time for Election* > Returning Officer R. B. COUSINS Wednesday received a reply from Chief > Electoral Officer N. Castonguay, in Ottawa, ruling on the matter of time > changes in Yukon affecting the territorial by-election in Whitehorse West > next Monday. His Message read as follows: > "Commissioner's Order 1966-20, dated January 27, 1966, provides from and > after midnight February 26, Yukon Standard Time as defined by section 36 of > the Interpretation Ordinance shall be reckoned in the same manner as > Pacific Standard Time. That is eight hours behind Greenwich Mean Time for > the area lying east of 136 degrees longitude and west and south of 62 > degrees latitude. In the remainder of the territory Yukon standard time > shall be reckoned as nine hours behind Greenwich mean time. This means > that in Whitehorse, Yukon Standard Time is eight hours behind Greenwich > Mean Time and all operations of Canada Elections Act in your electoral > district are governed by Yukon Standard Time. Advise all candidates and > other parties interested." > In other words, Yukon time in Whitehorse Monday for purposes of voting > will be the same as anything else... Yukon Southern Standard. https://www.newspapers.com/image/578577076/ There is a typo in this article where it says "and west and south". It presumably should have stated "lying east of 136° West longitude and south of 62° North latitude". *This change is not currently reflected in the TZ database; it should be applied to America/Whitehorse as a permanent change from UTC-9(YST) to UTC-8(PST) at 00:00 on Sunday February 27, 1966.* Zones in need of fixing: America/Whitehorse ---------------------------------------------------------------------------------------- *Item C: On Sunday May 28, 1967, the Yukon redefined the boundary between UTC-9 and UTC-8 to be a single straight line running along the 138th Meridian.* This change was a result of Commissioner's Order 1967-59 which can be seen at https://articles.adsabs.harvard.edu//full/1970JRASC..64..129T/0000156.000.h… page 156. Brian Inglis already quoted the Commissioner's Order on this mailing list (in the same posting I mentioned for item B above), but I will provide it again here. > COMMISSIONER'S ORDER 1967-59: > 1. Commissioner's Order 1966-20 dated at Whitehorse in the Yukon > Territory on 27th January, 1966, is hereby revoked. > 2. Yukon (East) Standard Time as defined by section 36 of the > Interpretation Ordinance from and after mid-night on the 28th day of May, > 1967 shall be reckoned in the same manner as Pacific Standard Time, that is > to say, eight hours behind Greenwich Time in the area of the Yukon > Territory lying east of the 138th degree longitude west. > 3. In the remainder of the Territory, lying west of the 138th degree > longitude west, Yukon (West) Standard Time shall be reckoned as nine hours > behind Greenwich Time. News article: *Whitehorse Star *—* Thursday May 11, 1967 *—* page 1* title: *Don't Touch That Clock* > The Yukon will be going on a new double time system after midnight May 28 > but Whitehorse residents won't notice the change. > Neither will most of the residents in other Yukon communities. > The change will place everyone on the east side of the 138 meridian on > Pacific Standard Time which is the same as Yukon Southern Standard Time > which is the same as Yukon Eastern Standard Time which is what most of > these people are on now. > Everyone on the west side of the 138th meridian will be on Yukon Standard > Time, or nine hours behind Greenwich time, which is Yukon Northern Standard > Time which is Yukon Western Standard Time, which is what they're on now. > The meridian runs north and south through the territory, passing near > Gravel Lake on the Stewart-Dawson Road, and just past Haines Junction on > the Alaska Highway. > This means that residents of Haines Junction, who petitioned for the > change several months ago, will now be on the same time as Whitehorse, > moving their clocks ahead one hour at midnight May 28. The same applies to > Carmacks residents, and some in Mayo and Keno. > Elsa adopted Whitehorse time for practical business reasons some time ago. > Announcing the forthcoming change to Territorial Council this week, > Commissioner J. Smith said the new system will be tried for a year and if > it doesn't work out, the entire territory will revert to one time zone > again. https://www.newspapers.com/image/578592950/ The Commissioner's Order and the newspaper article both refer to "midnight" on May 28. This possibly should be interpreted as "00:00 Sunday May 28" instead of "24:00 Sunday May 28" because a scheduled change for a Sunday night seems unlikely. However, the exact time and date is moot for the purposes of the TZ database because the change did not affect either Dawson City or Whitehorse. If it were not for the 1970 cutoff policy in the TZ database, we would need a new zone named "America/Carmacks" or "America/Haines_Junction"... and only then would we need to worry about the exact date and time of the transition. It seems like we might also have needed "America/Elsa". *The TZ database currently shows America/Whitehorse changing from UTC-9 to UTC-8 at 00:00 May 28, 1967; this rule is incorrect because Whitehorse had already transitioned to UTC-8 the year before. See item (B) above.* Zones in need of fixing: America/Whitehorse ---------------------------------------------------------------------------------------- *Item D: The Northwest Territories has been using daylight saving every summer since 1972.* News article 1: *Whitehorse Star *—* Friday April 28,1972 *—* page 6* title: *Daylight Saving Time for N.W.T.* > The Northwest Territories goes on daylight saving time at 2 a.m. on Sunday > when residents will set their clocks ahead one hour. > The only exception is the community of Coral Harbour on Southampton Island > which will remain unchanged in order that residents there will be on the > same time as those in the Keewatin. > Coral Harbour is in the eastern time zone and is one hour ahead of the > Keewatin region which operates in the central time zone. > Daylight saving time in the Territories is necessary to eliminate the > confusion in work hours between northern and southern Canada. > The move is being made because Alberta will be going on daylight saving > time for the first time on a province-wide basis at the same time. > If the NWT did not follow suit, all Alberta communities would be one hour > ahead of communities in the Mackenzie District of the NWT causing > difficulties and confusion in respect to transportation scheduling and > radio programming https://www.newspapers.com/image/578701610/ <https://www.newspapers.com/image/578701610/> The implication is that NWT started using daylight saving at 2:00a.m. on Sunday April 30,1972 which matches the records we have for Alberta. Note: there is a blog about this at https://cabinradio.ca/91751/news/remembering-the-start-of-daylight-saving-i… The blog has an image of the same newspaper article; it claims the article was published on April 18 instead of April 28 but that is an error. Another bit of proof that NWT (and much of Canada) was already using daylight saving prior to 1980 lies in the wording of the following Yukon article: *Whitehorse Star *—* Friday April 25,1980 *—* page 1* title: *Turn Your Clock Ahead Sunday* > As of 2 a.m next Sunday, Yukoners will become the last people across > Canada to join the ranks of the enlightened — on daylight saving time. > Clocks will be turned ahead one hour. That means on Sunday morning, what > was 7:00 last week will then be 8:00. Standard time resumes next October. > So you'll get one less hour's sleep tomorrow night. Daylight saving is > said to save on energy and even reduce crime. But don't lose any sleep over > it. https://www.newspapers.com/image/578597701/ Obviously I would have preferred to cite a Yellowknife (NWT) newspaper instead of a Whitehorse (Yukon) newspaper, but I could not find online archives of Yellowknife newspapers for the applicable time frame. *Nunavut and NWT zones should be updated in the TZ database to show observance of DST starting in 1972 instead of 1980.Start and End dates should be the same as the rest of Canada (last Sunday in April to last Sunday in October) with all transitions at 2:00a.m.* Zones in need of fixing: America/Yellowknife (NWT) America/Inuvik (NWT) America/Iqaluit (Nunavut) America/Cambridge_Bay (Nunavut) America/Pangnirtung (Nunavut) America/Rankin_Inlet (Nunavut) America/Resolute (Nunavut) Note that no changes are required for the two Yukon zones that correctly show Yukon reinstating daylight saving in 1980. ---------------------------------------------------------------------------------------- *Item E: Pangnirtung* A comment in the TZ database northamerica file reads: "Pangnirtung switched to eastern time; we'll guess 1995." Context: The communities of Pangnirtung and Qikiqtarjuaq (Broughton Island) are located on the east side of Baffin Island in Nunavut; they sit east of 68°W and according to the old NWT legislation, they were both supposed to have been on Atlantic Time. The 5th edition of the Atlas of Canada contains a time zone map that shows both legislated and observed time zone boundaries. All communities on Baffin Island are shown to be *observing *Eastern time. The date on the map is 1984. https://ftp.maps.canada.ca/pub/nrcan_rncan/raster/atlas_5_ed/eng/other/ referencemaps/mcr4056.pdf The implication is that Pangnirtung and Qikiqtarjuaq have observed Eastern Time as far back as 1984 (and likely even further back than that). It is possible that these communities never actually observed Atlantic Time, but that would be difficult to prove. *The TZ database rules for America/Pangirtung should be adjusted to show Eastern Time as far back as at least 1984.* Theoretically the zone could also be moved to the backzone file due to lack of any reliable history between 1970 and 1984; but I am not going to actively push for that. Zones in need of fixing: America/Pangnirtung (Nunavut) FYI: There is an older time zone map in the 4th edition of the Atlas of Canada. It has a date of 1967. Unfortunately it shows only the legislated boundaries which are not useful to us. https://ftp.maps.canada.ca/pub/nrcan_rncan/raster/atlas_4_ed/eng/economic/ transportationandcommunications/225_226.pdf ---------------------------------------------------------------------------------------- -chris

2 2

Bug in 2022f version of zic.c
by Tim McBrayer Nov. 7, 2022

Nov. 7, 2022

Hi, tzcode2022f/zic.c has a bug in its memory checker routine in static void* memcheck(void*). This code throws an error and exits when the pointer returned by malloc is NULL. However, malloc is allowed to return a NULL pointer when the allocation size is 0. And, on one machine I am building the TZ code on, malloc(0) does indeed return NULL. This is an AIX 6.1 box, with C compiler xlC 13.01.0000.0011. This is easy enough to work around locally. However, it would be nice to get this fixed for any future release of the TZ code. --- Tim McBrayer Ab Initio Software NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.

4 4

[PROPOSED] Generate nicer 'make check' output
by Paul Eggert Nov. 6, 2022

Nov. 6, 2022

* Makefile (DIFF_TZS): New macro. (check_tzs, $(TIME_T_ALTERNATIVES)): Use it. --- Makefile | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 8c4c6aba..9ee15607 100644 --- a/Makefile +++ b/Makefile @@ -499,6 +499,11 @@ TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ # Flags to give 'gzip' when making a distribution. GZIPFLAGS= -9n +# When comparing .tzs files, use GNU diff's -F'^TZ=' option if supported. +# This makes it easier to see which Zone has been affected. +DIFF_TZS= diff -u$$(! diff -u -F'^TZ=' - - <>/dev/null >&0 2>&1 \ + || echo ' -F^TZ=') + ############################################################################### #MAKE= make @@ -857,7 +862,7 @@ check_tables: checktab.awk $(YDATA) backward $(ZONETABLES) check_tzs: $(TZS) $(TZS_NEW) if test -s $(TZS); then \ - diff -u $(TZS) $(TZS_NEW); \ + $(DIFF_TZS) $(TZS) $(TZS_NEW); \ else \ cp $(TZS_NEW) $(TZS); \ fi @@ -1058,7 +1063,7 @@ $(TIME_T_ALTERNATIVES): $(VERSION_DEPS) TZS_YEAR="$$range" TZS_CUTOFF_FLAG="-t $$range" \ D=$$wd/$@.dir \ to$$range.tzs) && \ - diff -u $(TIME_T_ALTERNATIVES_HEAD).dir/to$$range.tzs \ + $(DIFF_TZS) $(TIME_T_ALTERNATIVES_HEAD).dir/to$$range.tzs \ $@.dir/to$$range.tzs && \ if diff -q Makefile Makefile 2>/dev/null; then \ quiet_option='-q'; \ -- 2.37.2

1 0

[PROPOSED] Fix unlikely conversion bug in zic
by Paul Eggert Nov. 5, 2022

Nov. 5, 2022

* zic.c (puttzcode): Arg is zic_t, not int_fast32_t. This fixes a portability bug on platforms where int_fast32_t is a 32-bit ones’ complement or signed-magnitude integer, and where the argument is -2**31 before conversion to int_fast32_t. Although I don’t know of any such platforms, the C standard allows them. --- zic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.c b/zic.c index d8bdbb96..548c1c5f 100644 --- a/zic.c +++ b/zic.c @@ -2216,7 +2216,7 @@ convert64(uint_fast64_t val, char *buf) } static void -puttzcode(const int_fast32_t val, FILE *const fp) +puttzcode(zic_t val, FILE *fp) { char buf[4]; -- 2.37.2

2 1

Mexico on track to abolish DST
by Paul Eggert Nov. 3, 2022

Nov. 3, 2022

Yesterday Mexico's Chamber of Deputies voted 445–33 to abolish DST in most of Mexico, and although there are more hurdles I expect this to become law. When that happens, I hope the following simple patch will suffice; it merely changes "max" to "2022" in the last two Mexico Rule lines. We'll also need to add commentary citing the law, etc., but you can try this patch now if you like, to debug any applications involving future time in Mexico. Today timeanddate updated their English-language summary of this <https://www.timeanddate.com/news/time/mexico-remove-dst-2022.html>. I haven't installed the following. diff --git a/northamerica b/northamerica index da84f354..2466d627 100644 --- a/northamerica +++ b/northamerica @@ -2634,2 +2634,2 @@ 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

4 16

Re: [tz] iana build failures on Windows
by Paul Eggert Nov. 2, 2022

Nov. 2, 2022

On 4/19/21 7:09 AM, Manuela Friedrich wrote: > I had to include signal.h in zic.c to prevent the following error: > > zic.c(610): error C2061: syntax error: identifier 'got_signal' This is a portability bug recently introduced to zic.c. I installed the first attached patch to fix it. > The I needed to resolved error > > zic.obj : error LNK2019: unresolved external symbol tz_time referenced in function random_dirent This appears to be another recent portability bug. It's related to a portability problem you reported on MS-Windows in response to which in 2018d I committed a patch that introduced RESERVE_STD_EXT_IDS: https://github.com/eggert/tz/commit/24b45243c5210b4196987fdd06e6c288c358a268 When I recently added the randomish filename code to the development version, I neglected to deal with RESERVE_STD_EXT_IDS. The second attached patch should fix this issue. Please give the two patches a try, as I don't use MS-Windows and can't easily test these patches on that platform. > a test run of zdump -v produced way more output than in the last release, the Linux output seems to have become longer too, but maybe this is still under development. That change is intentional, and was caused by this: https://github.com/eggert/tz/commit/ac07b446a3afaa4cb1ae11a91785a201c91f6351 along with some neighboring commits. Thanks for reporting the problems, and I hope the current development version of tzdb addresses the issues you mentioned.

5 23

Errors compiling 2022f on macOS
by Gilmore Davidson Nov. 1, 2022

Nov. 1, 2022

Hi, I’m getting errors when running make on the 2022f release, on my macOS Monterrey (12.6.1) machine. There are two separate errors. When I run `make` with no arguments, I get the following: cc -DTZDIR='"/usr/share/zoneinfo"' -c -o zic.o zic.c zic.c:1194:11: error: implicit declaration of function 'getrandom' is invalid in C99 [-Werror,-Wimplicit-function-declaration] s = getrandom(entropy_buffer, sizeof entropy_buffer, 0); ^ 1 error generated. After some digging, I tried running `make CFLAGS="-DHAVE_GETRANDOM=0”`, which then presents a different error: cc -DTZDIR='"/usr/share/zoneinfo"' -o zic -DHAVE_GETRANDOM=0 zic.o Undefined symbols for architecture x86_64: "_libintl_gettext", referenced from: _main in zic.o _close_file in zic.o _usage in zic.o _warning in zic.o _infile in zic.o _adjleap in zic.o _associate in zic.o ... "_libintl_setlocale", referenced from: _main in zic.o "_libintl_textdomain", referenced from: _main in zic.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) I’m not a C programmer so I’m out of my depth with trying to diagnose workarounds. Possibly there’s just another CFLAGS argument I need to provide, or I’ve got something else weird in my environment? Some extra bits of context: These errors also happen on latest `main` branch (commit 9f1f40cd). I can compile 2022e without issue. The getrandom error appears in commit 0733c65c ("Improve randomness of zic temp file names”). The linking error appears in commit e5b2ee63 ("Use C23 __has_include if available”). masOS 12.6.1 / Make 3.81 / clang 14.0.0 Also, the Makefile comment for the HAVE_GETRANDOM flag says "-DHAVE_GETRANDOM if getgrandom works (e.g., GNU/Linux)*” — is “getgrandom” a typo? Cheers, Gil

4 13

zic.c - compilation broken on gcc 4.8.3 after commit e5b2ee634c7151484c06740ea2c8a4d4a75409b6
by Иванов Игорь Oct. 31, 2022

Oct. 31, 2022

Good time of day. This commit breaks compilation at least on GCC 4.8.3: commit e5b2ee634c7151484c06740ea2c8a4d4a75409b6 Author: Paul Eggert <eggert(a)cs.ucla.edu> Date: Thu Oct 20 11:41:27 2022 -0700 Use C23 __has_include if available It causes this compilation error: zic.c: In function ‘main’: zic.c:813:16: error: ‘optarg’ undeclared (first use in this function) if (strcmp(optarg, "slim") == 0) { ^ zic.c:906:6: error: ‘optind’ undeclared (first use in this function) if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) ^ Specifically hunks like this are problematic: @@ -55,8 +63,8 @@ #endif #ifndef HAVE_GETTEXT -# define HAVE_GETTEXT 0 -#endif /* !defined HAVE_GETTEXT */ +# define HAVE_GETTEXT HAS_INCLUDE(<libintl.h>, false) +#endif #ifndef HAVE_INCOMPATIBLE_CTIME_R # define HAVE_INCOMPATIBLE_CTIME_R 0 The culprit is the replacement 0 -> false and 1 -> true. Apparently it breaks #if preprocessor logic in older compilers somewhere downstream - what was #if 1 becomes #if true, which GCC treats as "false" and falls into #else branch. "Restoring" false and true back to 0 and 1 seems to fix the issue. Best regards, Igor Ivanov, Software engineer at DSSL

2 3

Syria Time has changed
by Rami M Oct. 31, 2022

Oct. 31, 2022

2 1

Grouped country lists are confusing
by Stephen Colebourne Oct. 31, 2022

Oct. 31, 2022

Recent changes merged the comments acting as country headers. Thus, a typical merged header is now: # Denmark # Germany # Norway # Sweden It is very confusing to suggest that all four countries are evenly represented here, as the commentary is typically all about the primary country (Germany in this case). The alphabetical list is decidedly unhelpful too, as nothing indicates which country the Zone's city relates to. Can I propose these comments be altered to something like: # Germany # also applicable since 1970 to Denmark # also applicable since 1970 to Norway # also applicable since 1970 to Sweden thanks Stephen

4 6