- tz - lists.iana.org

New York Times: Time is Running Out for the Leap Second
by Jonathan Leffler Nov. 15, 2022

Nov. 15, 2022

https://www.nytimes.com/2022/11/14/science/time-leap-second.html -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

United States Senate reintroduced Sunshine Protection Act, enabling Permanent DST
by Phake Nick Nov. 14, 2022

Nov. 14, 2022

I don't quite understand the legal text of the bill itself [2], but according to my reading, it seems like the bill will end DST across the entire US by shifting the standard time forward an hour, except in states/territories/area that currently doesn't enact DST, which they can choose to follow the new standard time or old standard time? 1: https://www.rubio.senate.gov/public/index.cfm/2021/3/rubio-colleagues-reint… 2: https://www.rubio.senate.gov/public/_cache/files/d34c77c0-acea-4074-bc57-14…

18 26

[PATCH] use official source for 1993 end of time shift
by Alois Treindl Nov. 12, 2022

Nov. 12, 2022

--- southamerica | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/southamerica b/southamerica index 13cc65e..8eb5e25 100644 --- a/southamerica +++ b/southamerica @@ -1417,10 +1417,13 @@ Zone Antarctica/Palmer 0 - -00 1965 # Milne gives 4:56:16.4 for Bogotá time in 1899. He writes, # "A variation of fifteen minutes in the public clocks of Bogota is not rare." +# Alois Treindl quoted DECRETO 267 DE 1993 +# https://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Decretos/1061335 +# Artículo 2° El cambio de hora se hará efectivo a las veinticuatro horas del día 6 de febrero del presente año. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule CO 1992 only - May 3 0:00 1:00 - -Rule CO 1993 only - Apr 4 0:00 0 - +Rule CO 1993 only - Feb 7 0:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] #STDOFF -4:56:16.4 Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 -- 1.8.3.1

2 1

Re: [tz] Minor (unimportant really) technical UB bug in strftime() ?
by Brian Inglis Nov. 12, 2022

Nov. 12, 2022

On 2022-11-11 13:53, Paul Eggert via tz wrote: > On 2022-11-10 16:11, Tom Lane wrote: > >> simple modifications of the >> strftime() case can provide pretty good examples. > I'm not sure I'm following this argument, but if I understand it correctly I > disagree. I very much much want implementations to reject attempts to use > uninitialized data, and I don't want the C standard to prohibit such > implementations. Use of uninitialized data is a serious problem in real > applications - several CVEs have arisen from it - and the C standard shouldn't > require implementations to sweep it under the rug. > This call is obviously buggy since it is passing an uninitialized struct tm to > strftime. However, the C standard says the patched strftime's memcpy initializes > strftime's local variable tm, and therefore mktime's use of tm's contents is > defined and the implementation allow the program's use of uninitialized data. > > Whatever the reason for this peculiarity of the C standard (and nobody seems to > remember why it's there), it's counterproductive. In general C programs > shouldn't use uninitialized data. If they do, it's useful to have a debugging > implementation that reports any such use the instant that it happens as this > will help catch real bugs. And since common debugging implementations like > valgrind and UBSan are not following the C standard here, this suggests that the > C standard is mistaken, not the implementations. >> That leads either to strftime() knowing >> much more about mktime()'s innards than it ought to > It's not a problem for strftime, since strftime's has to know what's needed in > the struct tm; this follows from strftime's API. It may not know everything about the object, as there may be implementatiion extensions to deal with e.g. localization issues, and can never know everything about another function implementation, which could be changed at any time. > It might be a problem for other scenarios, such as the one you vaguely suggested > though I don't know the details. However, even assuming these other scenarios > exist, they don't justify this peculiarity of the C standard. The standard > should not say that the ordinary meaning of "don't use uninitialized variables" > is wrong and that there's some trickier interpretation that hardly any > programmer knows and that was wrong even in C17 and so needed rewording (and > perhaps still needs rewording) and that nevertheless must be supported - even > though important debugging implementations disagree. I think the principle is just to program carefully and generically around possible issues, when dealing with an opaque object you do not define and control, to avoid creating issues with private fields or functions which may be part of the implementation, but not in whatever documented interface you are programming to. Not all the world is...C, POSIX, or Linux, compliant. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

Minor (unimportant really) technical UB bug in strftime() ?
by Robert Elz Nov. 11, 2022

Nov. 11, 2022

The code for the %s strftime conversion starts as: (this taken from tzcode2022f strftime.c - but I suspect that many versions are the same) case 's': { struct tm tm; char buf[INT_STRLEN_MAXIMUM( time_t) + 1]; time_t mkt; tm = *t; mkt = mktime(&tm); The "tm = *t;" line is the problem. It (or more correctly, something to replace that) is needed, as *t is const, strftime() is not permitted to modify it, yet the struct tm * passed to mktime() is not const, as mktime is sometimes required to modify that struct before returning. However, mktime() refers only to the fields tm_year tm_mon tm_mday tm_hour tm_min tm_sec and tm_isdst of the struct passed to it. The %s conversion is defined as producing (in a decimal string format) the result of mktime() applied to the struct tm passed to strftime. Hence an application which intends to use strftime(..., "%s", ...) need only initialise those 7 fields, the other 2 (currently) standard fields (tm_yday and tm_wday) are explicitly ignored by mktime() on input, so there is no need to assign those values, and any other fields that might exist in a particular implementation are out of scope for a portable (conforming) application to touch, so cannot be initialised. Since referring to an uninitialised variable is, I believe, technically undefined behaviour, doing a struct copy (copying all fields) can have that effect. (An application could memset() the entire struct before providing the values it must add, but is not required to do that). It seems likely that the simple fix is to replace the struct assignment with 7 individual assignment statements tm.tm_year = t->tm_year; tm.tm_mon = t->tm_mon; /* ... */ On the other hand, hardware that balks at simply loading or copying, uninitialised values, without using them for any purpose is not exactly common (and half the world's code would probably break if an implementation that worked in such a manner was ever created) so I'd call this one of the less significant issues to worry about fixing. kre

10 26

End of time change in Colombia 1993
by Alois Treindl Nov. 10, 2022

Nov. 10, 2022

TZ has for Colombia a single period with time zone 4h west. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule CO 1992 only - May 3 0:00 1:00 - Rule CO 1993 only - Apr 4 0:00 0 - I think the end date 4 April is wrong, it should be 6 February 24h or 7 February 0h The time shift was called Hora Gaviria, and caused by shortage of electricity in connection with El Niño . Source: *DECRETO 267 DE 1993 * https://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Decretos/1061335 *Artículo 1° *Adoptar como hora legal en el territorio de la República, la del Tiempo Universal Coordinado, UTC, disminuido en cinco (5) horas. *Artículo 2° *El cambio de hora se hará efectivo a las veinticuatro horas del día 6 de febrero del presente año. There is also a newspaper article https://www.eltiempo.com/archivo/documento/MAM-32922 of 4 feb 1993, but the text is less clear to my limited understanding of Spanish. See also https://es.wikipedia.org/wiki/Crisis_energ%C3%A9tica_de_1992_en_Colombia **

1 1

[PROPOSED] Support timegm by default, as per C23
by Paul Eggert Nov. 10, 2022

Nov. 10, 2022

Also, fix a bug in timegm; it sometimes modified its input even on failure. * Makefile, NEWS: Mention this. * localtime.c (mktmcpy): New static function. (time2sub): Use it. (timegm, timeoff): Define even if !STD_INSPIRED. (timeoff): Make it static if !STD_INSPIRED. (timegm): Do not modify *TMP on failure, even if only to change TMP->is_isdst. * private.h (HAVE_DECL_TIMEGM): Specify reasonable default value. (timegm): Always declare one way or another. --- Makefile | 8 +++----- NEWS | 5 +++++ localtime.c | 53 +++++++++++++++++++++++++++++++++-------------------- private.h | 18 +++++++++++++++--- 4 files changed, 56 insertions(+), 28 deletions(-) diff --git a/Makefile b/Makefile index 9ee15607..5ec0d4ab 100644 --- a/Makefile +++ b/Makefile @@ -209,6 +209,7 @@ LDLIBS= # For example, N is 252460800 on AmigaOS. # -DHAVE_DECL_ASCTIME_R=0 if <time.h> does not declare asctime_r # -DHAVE_DECL_ENVIRON if <unistd.h> declares 'environ' +# -DHAVE_DECL_TIMEGM=0 if <time.h> does not declare timegm # -DHAVE_DIRECT_H if mkdir needs <direct.h> (MS-Windows) # -DHAVE_GENERIC=0 if _Generic does not work* # -DHAVE_GETRANDOM if getrandom works (e.g., GNU/Linux), @@ -344,14 +345,11 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # If you want functions that were inspired by early versions of X3J11's work, # add # -DSTD_INSPIRED -# to the end of the "CFLAGS=" line. This arranges for the functions -# "offtime", "timelocal", "timegm", "timeoff", -# "posix2time", and "time2posix" to be added to the time conversion library. +# to the end of the "CFLAGS=" line. This arranges for the following +# functions to be added to the time conversion library. # "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". -# "timegm" is like "timelocal" except that it turns a struct tm into -# a time_t using UT (rather than local time as "timelocal" does). # "timeoff" is like "timegm" except that it accepts a second (long) argument # that gives an offset to use when converting to a time_t. # "posix2time" and "time2posix" are described in an included manual page. diff --git a/NEWS b/NEWS index 4a053077..23f1f7f1 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,7 @@ News for the tz database Briefly: Fix some pre-1996 timestamps in northern Canada + C23 timegm now supported by default Unreleased, experimental changes @@ -22,6 +23,10 @@ Unreleased, experimental changes Changes to code + timegm, which tzcode implemented in 1989, will finally be + standardized 34 years later as part of C23, so timegm is now + supported even if STD_INSPIRED is not defined. + Fix bug in zdump's tzalloc emulation on hosts that lack tm_zone. (Problem reported by Đoàn Trần Công Danh.) diff --git a/localtime.c b/localtime.c index 712be135..9935b5d3 100644 --- a/localtime.c +++ b/localtime.c @@ -1951,6 +1951,23 @@ tmcomp(register const struct tm *const atmp, return result; } +/* Copy to *DEST from *SRC. Copy only the members needed for mktime, + as other members might not be initialized. */ +static void +mktmcpy(struct tm *dest, struct tm *const src) +{ + dest->tm_sec = src->tm_sec; + dest->tm_min = src->tm_min; + dest->tm_hour = src->tm_hour; + dest->tm_mday = src->tm_mday; + dest->tm_mon = src->tm_mon; + dest->tm_year = src->tm_year; + dest->tm_isdst = src->tm_isdst; +#if defined TM_GMTOFF && ! UNINIT_TRAP + dest->TM_GMTOFF = src->TM_GMTOFF; +#endif +} + static time_t time2sub(struct tm *const tmp, struct tm *(*funcp)(struct state const *, time_t const *, @@ -1972,17 +1989,7 @@ time2sub(struct tm *const tmp, struct tm yourtm, mytm; *okayp = false; - - yourtm.tm_sec = tmp->tm_sec; - yourtm.tm_min = tmp->tm_min; - yourtm.tm_hour = tmp->tm_hour; - yourtm.tm_mday = tmp->tm_mday; - yourtm.tm_mon = tmp->tm_mon; - yourtm.tm_year = tmp->tm_year; - yourtm.tm_isdst = tmp->tm_isdst; -#if defined TM_GMTOFF && ! UNINIT_TRAP - yourtm.TM_GMTOFF = tmp->TM_GMTOFF; -#endif + mktmcpy(&yourtm, tmp); if (do_norm_secs) { if (normalize_overflow(&yourtm.tm_min, &yourtm.tm_sec, @@ -2289,7 +2296,6 @@ mktime(struct tm *tmp) } #ifdef STD_INSPIRED - time_t timelocal(struct tm *tmp) { @@ -2297,13 +2303,9 @@ timelocal(struct tm *tmp) tmp->tm_isdst = -1; /* in case it wasn't initialized */ return mktime(tmp); } - -time_t -timegm(struct tm *tmp) -{ - return timeoff(tmp, 0); -} - +#else +static +#endif time_t timeoff(struct tm *tmp, long offset) { @@ -2313,7 +2315,18 @@ timeoff(struct tm *tmp, long offset) return time1(tmp, gmtsub, gmtptr, offset); } -#endif /* defined STD_INSPIRED */ +time_t +timegm(struct tm *tmp) +{ + time_t t; + struct tm tmcpy; + mktmcpy(&tmcpy, tmp); + tmcpy.tm_wday = -1; + t = timeoff(&tmcpy, 0); + if (0 <= tmcpy.tm_wday) + *tmp = tmcpy; + return t; +} static int_fast32_t leapcorr(struct state const *sp, time_t t) diff --git a/private.h b/private.h index 7cbd56d2..7320173f 100644 --- a/private.h +++ b/private.h @@ -543,9 +543,24 @@ struct tm *localtime(time_t const *); struct tm *localtime_r(time_t const *restrict, struct tm *restrict); time_t mktime(struct tm *); time_t time(time_t *); +time_t timegm(struct tm *); void tzset(void); #endif +#ifndef HAVE_DECL_TIMEGM +# if (202311 <= __STDC_VERSION__ \ + || defined __GLIBC__ || defined __tm_zone /* musl */ \ + || defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__ \ + || (defined __APPLE__ && defined __MACH__)) +# define HAVE_DECL_TIMEGM true +# else +# define HAVE_DECL_TIMEGM false +# endif +#endif +#if !HAVE_DECL_TIMEGM && !defined timegm +time_t timegm(struct tm *); +#endif + #if !HAVE_DECL_ASCTIME_R && !defined asctime_r extern char *asctime_r(struct tm const *restrict, char *restrict); #endif @@ -582,9 +597,6 @@ extern long altzone; # if TZ_TIME_T || !defined offtime struct tm *offtime(time_t const *, long); # endif -# if TZ_TIME_T || !defined timegm -time_t timegm(struct tm *); -# endif # if TZ_TIME_T || !defined timelocal time_t timelocal(struct tm *); # endif -- 2.37.2

1 0

No Daylight Savings in Fiji For year 2022-2023
by Jashneel Kumar Nov. 9, 2022

Nov. 9, 2022

Dear Timezone Support, I would like to inform you that there will be no Daylight Saving in Fiji this year. Can you please check that the same is reflected in the time zone database. Regards, [New_VF_Icon_RGB_RED] Jashneel Kumar Manager Data Networks & Services Jashneel.Kumar(a)vodafone.com.fj<mailto:Jashneel.Kumar@vodafone.com.fj> Vodafone Fiji PTE Limited, 168 Princes Rd, Tamavua, Suva, Fiji Islands www.vodafone.com.fj<http://www.vodafone.com.fj/> Together we can [Vodafone] ________________________________ The content of this email including any attachments is confidential and may contain information that is proprietary and privileged. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify E-mail Administrator on info(a)vodafone.com.fj Please also destroy and delete this message from your system. Vodafone Fiji PTE Limited does not guarantee that this message is free from computer virus or any other defect. The reader accepts full responsibility for taking defensive and counteractive action needed to rectify the computer virus or other defects caused. Vodafone Fiji PTE Limited : Private Mail Bag, Suva, Fiji | Telephone : +679 3312000 | E-Mail : info(a)vodafone.com.fj Please consider your environmental responsibility before printing this e-mail [https://www.vodafone.com.fj//images/default-source/logo/logo-2x.png] Vodafone Fiji PTE Ltd <https://www.vodafone.com.fj/>

3 5

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