- tz - lists.iana.org

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

[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