March 2017 - tz - lists.iana.org

proposed time zone package changes (Samoa, Factory, et al.)
by Arthur David Olson Aug. 28, 2019

Aug. 28, 2019

Below find proposed time zone package changes; the executive summary: * Makefile Change LOCALTIME default from "Factory" to "GMT"; do not compile "factory" file (but keep it in the distribution). * Theory Remove reference to "Factory" zone. * australasia Change end of DST in Samoa in 2011 from 2011-04-03 0:00 to 2011-04-03 1:00 (thanks to Raymond Hughes for a reference). * localtime.c Initialize ttinfo structures filled by tzparse (thanks to Ravindra for reporting a valgrind warning). * zic.c Fix generation of POSIX strings for zones with rules using "weekday<=n" forms of dates (thanks to Lei Liu for finding the problem). Also, limit output for non-POSIX-specificable zones defined to follow the same rules every year. (Note that no zones of either of the above types appear in the distribution; these changes cater to add-on zones). If no problems are found, 2010n will appear on 2010-10-25. --ado diff -r -c old/Makefile new/Makefile *** old/Makefile Mon Sep 27 09:24:25 2010 --- new/Makefile Tue Oct 12 12:36:50 2010 *************** *** 1,5 **** # <pre> ! # @(#)Makefile 8.8 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)Makefile 8.9 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 12,18 **** # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= Factory # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, --- 12,18 ---- # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= GMT # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, *************** *** 262,269 **** DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera factory backward ! NDATA= systemv SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab --- 262,269 ---- DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera backward ! NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab diff -r -c old/Theory new/Theory *** old/Theory Mon Sep 27 09:24:25 2010 --- new/Theory Tue Oct 12 12:36:50 2010 *************** *** 1,4 **** ! @(#)Theory 8.4 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. --- 1,4 ---- ! @(#)Theory 8.5 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. *************** *** 287,294 **** See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', `EET' (see the file `europe'), ! and `Factory' (see the file `factory'). ----- Time zone abbreviations ----- --- 287,293 ---- See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', and `EET' (see the file `europe'). ----- Time zone abbreviations ----- diff -r -c old/australasia new/australasia *** old/australasia Mon Sep 27 09:24:27 2010 --- new/australasia Tue Oct 12 13:14:56 2010 *************** *** 1,5 **** # <pre> ! # @(#)australasia 8.18 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)australasia 8.19 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 487,497 **** # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 -11:00 - WST # Solomon Is --- 487,507 ---- # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> + # From Raymond Hughes (2010-10-07): + # Please see + # <a href="http://www.mcil.gov.ws"> + # http://www.mcil.gov.ws + # </a>, + # the Ministry of Commerce, Industry and Labour (sideframe) "Last Sunday + # September 2010 (26/09/10) - adjust clocks forward from 12:00 midnight + # to 01:00am and First Sunday April 2011 (03/04/11) - adjust clocks + # backwards from 1:00am to 12:00am" + Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 1:00 -11:00 - WST # Solomon Is diff -r -c old/localtime.c new/localtime.c *** old/localtime.c Mon Sep 27 09:24:26 2010 --- new/localtime.c Tue Oct 12 12:36:51 2010 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.14"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.15"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 914,919 **** --- 914,920 ---- register unsigned char * typep; register char * cp; register int load_result; + static struct ttinfo zttinfo; INITIALIZE(dstname); stdname = name; *************** *** 986,991 **** --- 987,993 ---- /* ** Two transitions per year, from EPOCH_YEAR forward. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -dstoffset; sp->ttis[0].tt_isdst = 1; sp->ttis[0].tt_abbrind = stdlen + 1; *************** *** 1099,1106 **** } /* ** Finally, fill in ttis. - ** ttisstd and ttisgmt need not be handled. */ sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; --- 1101,1108 ---- } /* ** Finally, fill in ttis. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; *************** *** 1113,1118 **** --- 1115,1121 ---- dstlen = 0; sp->typecnt = 1; /* only standard time */ sp->timecnt = 0; + sp->ttis[0] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = 0; sp->ttis[0].tt_abbrind = 0; diff -r -c old/zic.c new/zic.c *** old/zic.c Mon Sep 27 09:24:26 2010 --- new/zic.c Tue Oct 12 13:37:29 2010 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.22"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.24"; #include "private.h" #include "locale.h" *************** *** 1881,1896 **** register int week; if (rp->r_dycode == DC_DOWGEQ) { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", --- 1881,1896 ---- register int week; if (rp->r_dycode == DC_DOWGEQ) { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 1) return -1; + week = 1 + rp->r_dayofmonth / DAYSPERWEEK; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 0) return -1; + week = rp->r_dayofmonth / DAYSPERWEEK; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", *************** *** 2018,2023 **** --- 2018,2024 ---- register char * envvar; register int max_abbr_len; register int max_envvar_len; + register int prodstic; /* all rules are min to max */ max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; *************** *** 2032,2037 **** --- 2033,2039 ---- timecnt = 0; typecnt = 0; charcnt = 0; + prodstic = zonecount == 1; /* ** Thanks to Earl Chew ** for noting the need to unconditionally initialize startttisstd. *************** *** 2053,2058 **** --- 2055,2062 ---- updateminmax(rp->r_loyear); if (rp->r_hiwasnum) updateminmax(rp->r_hiyear); + if (rp->r_lowasnum || rp->r_hiwasnum) + prodstic = FALSE; } } /* *************** *** 2075,2080 **** --- 2079,2094 ---- if (max_year <= INT_MAX - YEARSPERREPEAT) max_year += YEARSPERREPEAT; else max_year = INT_MAX; + /* + ** Regardless of any of the above, + ** for a "proDSTic" zone which specifies that its rules + ** always have and always will be in effect, + ** we only need one cycle to define the zone. + */ + if (prodstic) { + min_year = 1900; + max_year = min_year + YEARSPERREPEAT; + } } /* ** For the benefit of older systems,

5 6

Alberta Tory leadership candidate petitions to drop DST and move to CT
by Brian Inglis Sept. 19, 2017

Sept. 19, 2017

On the final day of the fall sitting on Tuesday, Alberta Progressive Conservative leadership candidate, Vermilion-Lloydminster MLA Richard Starke presented a petition to the legislature calling for repeal of the Daylight Saving Time Act and a move to Central Time (from Mountain Time), to be decided by a referendum. The stories linked below are all from the same news org and under the same byline. The latter two have a vote button at the bottom to poll readers' opinions, each currently running about 80/20 in favour of dropping DST, and/or possibly also of switching to permanent CT, depending on whether the voters read the question or just clicked. http://calgaryherald.com/news/politics/pc-leadership-candidate-starke-calls… http://www.edmontonjournal.com/news/politics/leadership+candidate+starke+ca… http://www.calgarysun.com/2016/12/14/to-keep-or-ditch-daylight-saving-time-… http://www.edmontonsun.com/2016/12/14/to-keep-or-ditch-daylight-saving-time… -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

6 14

Syntax highlighting for Sublime Text
by Gilmore Davidson Aug. 16, 2017

Aug. 16, 2017

Hi, I’ve created some tzdata syntax highlighting rules for the Sublime Text editor: https://packagecontrol.io/packages/zoneinfo <https://packagecontrol.io/packages/zoneinfo> I have no idea if anyone other than me uses that particular text editor for looking at tzdata files. But I thought I’d mention it just in case it’s useful to someone. Cheers, Gil

3 3

zone.tab / zone1970.tab inconsistency for TF/UM/VN
by Neil Fuller April 3, 2017

April 3, 2017

This may be a misunderstanding on my part about the file formats of zone.tab and zone1970.tab and how consistent they are expected to be. I expect the exact zone IDs to be different, but there are only a few cases where countries differ in the number of referenced zone IDs. I realize that zone.tab is intended for backward compatibility but it looks like it is being well maintained. Is this difference expected? If it is, can somebody explain? Details below the line. Thanks for all the hard work. Neil. ------------------- 2017b: TF zone.tab: TF -492110+0701303 Indian/Kerguelen zone1970.tab: RE,TF -2052+05528 Indian/Reunion Réunion, Crozet, Scattered Islands TF -492110+0701303 Indian/Kerguelen Kerguelen, St Paul Island, Amsterdam Island ------------------ UM zone.tab: UM +2813-17722 Pacific/Midway Midway Islands UM +1917+16637 Pacific/Wake Wake Island zone1970.tab: AS,UM -1416-17042 Pacific/Pago_Pago Samoa, Midway UM +1917+16637 Pacific/Wake Wake Island US,UM +211825-1575130 Pacific/Honolulu Hawaii ------------------ VN zone.tab: VN +1045+10640 Asia/Ho_Chi_Minh zone1970.tab: TH,KH,LA,VN +1345+10031 Asia/Bangkok Indochina (most areas) VN +1045+10640 Asia/Ho_Chi_Minh Vietnam (south) -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902

2 2

Re: [tz] Israel Timezone query
by Vidyalakshmi Badiger March 28, 2017

March 28, 2017

Dear Tz Team, As per the below request the Time zone value for Israel need to be changed from “GMT +2 (Default Value) to (Default value). So how can we proceed to provide this change? Regards, Vidya From: 황주연 [mailto:juyeon.hwang@lge.com] Sent: Tuesday, March 28, 2017 5:16 AM To: Vidyalakshmi Badiger/LGSIA MPS-7(vidya.badiger(a)lge.com) Cc: 김성경/책임연구원/MC연구소 SW플랫폼실 1팀 1파트(sungkyoung.kim(a)lge.com); Divya Srivastava/LGSIA MPS-7(divya.srivastava(a)lge.com); 황주연/선임연구원/MC연구소 SW플랫폼실 1팀 2파트(juyeon.hwang(a)lge.com) Subject: RE: Israel Timezone query Dear Vidyalakshmi Badiger, We not modify tzdata manually. I think you can contact IANA (tz(a)iana.org<mailto:tz@iana.org>) Thank you. From: Vidyalakshmi Badiger [mailto:vidya.badiger@lge.com] Sent: Monday, March 27, 2017 6:51 PM To: juyeon.hwang(a)lge.com<mailto:juyeon.hwang@lge.com> Cc: sungkyoung.kim(a)lge.com<mailto:sungkyoung.kim@lge.com>; Divya Srivastava <divya.srivastava(a)lge.com<mailto:divya.srivastava@lge.com>> Subject: FW: Israel Timezone query Dear Juyeon, As per the below request the Time zone value for Israel need to be changed from “GMT +2 (Default Value) to (Default value). So how can we proceed to provide this change? Regards, Vidya From: Vidyalakshmi Badiger/LGSIA MPS-7(vidya.badiger(a)lge.com<mailto:vidya.badiger@lge.com>) Sent: Thursday, March 23, 2017 6:27 PM To: Raghavendra Revankar/LGSIA MPS-7(raghavendra.revankar(a)lge.com<mailto:raghavendra.revankar@lge.com>); Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>); Satish K R/LGSIA MPS-7(satish.babu(a)lge.com<mailto:satish.babu@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>) Subject: RE: Israel Timezone query Dear Veena, Please find the details, Can you please confirm the current time zone value present in Google’s library for Israel all buyers? ---- GMT+02:00 Israel Standard Time [Jerusalem] what action need to be taken if the Google’s value is not matching with the above new GPRI change. ----- Need to check with HQ ,as we need to change time zone by modifying metaZones.txt Regards, Vidya From: Raghavendra Revankar/LGSIA MPS-7(raghavendra.revankar(a)lge.com<mailto:raghavendra.revankar@lge.com>) Sent: Thursday, March 23, 2017 5:56 PM To: Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>); Satish K R/LGSIA MPS-7(satish.babu(a)lge.com<mailto:satish.babu@lge.com>); Vidyalakshmi Badiger/LGSIA MPS-7(vidya.badiger(a)lge.com<mailto:vidya.badiger@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Nagappa Karajol/LGSIA MPS-7(nagappa.karajol(a)lge.com<mailto:nagappa.karajol@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>); Harshith C K/LGSIA MPS-7(harshith.ck(a)lge.com<mailto:harshith.ck@lge.com>) Subject: RE: Israel Timezone query ++ VIDYA From: Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>) Sent: Thursday, 23 March 2017 5:54 PM To: Satish K R/LGSIA MPS-7(satish.babu(a)lge.com<mailto:satish.babu@lge.com>); Raghavendra Revankar/LGSIA MPS-7(raghavendra.revankar(a)lge.com<mailto:raghavendra.revankar@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Nagappa Karajol/LGSIA MPS-7(nagappa.karajol(a)lge.com<mailto:nagappa.karajol@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>); Harshith C K/LGSIA MPS-7(harshith.ck(a)lge.com<mailto:harshith.ck@lge.com>) Subject: RE: Israel Timezone query ++ Raghavendra From: Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>) Sent: Thursday, March 23, 2017 10:01 AM To: Satish K R/LGSIA MPS-7(satish.babu(a)lge.com<mailto:satish.babu@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Nagappa Karajol/LGSIA MPS-7(nagappa.karajol(a)lge.com<mailto:nagappa.karajol@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>); Harshith C K/LGSIA MPS-7(harshith.ck(a)lge.com<mailto:harshith.ck@lge.com>) Subject: RE: Israel Timezone query Dear Satish, As requested in below mail, please let us know the Google’s IANA DB version used for all models for Timezone check. Regards, Veena. From: Harshith C K/LGSIA MPS-7(harshith.ck(a)lge.com<mailto:harshith.ck@lge.com>) Sent: Thursday, March 23, 2017 9:56 AM To: Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Nagappa Karajol/LGSIA MPS-7(nagappa.karajol(a)lge.com<mailto:nagappa.karajol@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>) Subject: RE: Israel Timezone query Dear Veena, As you mentioned, timezone is picked from IANA database shared by Google which is part of frameworks. Please check with CFW team for DB version details. Thanks & Regards, Harshith From: Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>) Sent: Thursday, March 23, 2017 9:41 AM To: Harshith C K/LGSIA MPS-7(harshith.ck(a)lge.com<mailto:harshith.ck@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Nagappa Karajol/LGSIA MPS-7(nagappa.karajol(a)lge.com<mailto:nagappa.karajol@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>) Subject: Israel Timezone query Dear Harshit, Recently we observed that Israel FTE has updated timezone for Partner buyer. Please refer below screenshot. [cid:image001.png@01D2A7AB.923BBB40] But as we are aware, time zone is no more referred from GPRI and Google’s library is used to for the same. Can you please confirm the current time zone value present in Google’s library for Israel all buyers? Also please let us know, what action need to be taken if the Google’s value is not matching with the above new GPRI change. Regards, Veena.

5 4

[PATCH] Fix some word repetitions
by Paul Eggert March 25, 2017

March 25, 2017

* Makefile, europe, localtime.c, tz-art.htm, tzfile.5: Fix repeated instances of words in commentary. (Problem with 'Makefile'reported by Curtis Manwaring.) --- Makefile | 2 +- europe | 2 +- localtime.c | 2 +- tz-art.htm | 2 +- tzfile.5 | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 8067ba0..87fcfab 100644 --- a/Makefile +++ b/Makefile @@ -75,7 +75,7 @@ LIBDIR= $(TOPDIR)/lib # If you want only POSIX time, with time values interpreted as # seconds since the epoch (not counting leap seconds), use # REDO= posix_only -# below. If you want want only "right" time, with values interpreted +# below. If you want only "right" time, with values interpreted # as seconds since the epoch (counting leap seconds), use # REDO= right_only # below. If you want both sets of data available, with leap seconds not diff --git a/europe b/europe index 558b9f1..088d0a8 100644 --- a/europe +++ b/europe @@ -1524,7 +1524,7 @@ Zone Atlantic/Reykjavik -1:28 - LMT 1908 # 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 using C-Eur rules from 1943-09-10 +# 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. # diff --git a/localtime.c b/localtime.c index afc7438..4bedb5c 100644 --- a/localtime.c +++ b/localtime.c @@ -639,7 +639,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, } } /* - ** If type 0 is is unused in transitions, + ** If type 0 is unused in transitions, ** it's the type to use for early times. */ for (i = 0; i < sp->timecnt; ++i) diff --git a/tz-art.htm b/tz-art.htm index f726cce..17b8719 100644 --- a/tz-art.htm +++ b/tz-art.htm @@ -24,7 +24,7 @@ into problems that programmers have with timekeeping.</li> Explaining The Mysteries Of Time Zones</a>" (2017; 2:15) briefly says why France has more time zones than Russia.</a> <li> -"About Time" (1962; 53 minutes) is part of the the +"About Time" (1962; 53 minutes) is part of the Bell Science extravaganza, with Frank Baxter, Richard Deacon, and Les Tremayne. Its advisor was Richard Feynman, and it was voiced by Mel Blanc. (<a href="http://www.imdb.com/title/tt0154110/">IMDb entry</a>.)</li> diff --git a/tzfile.5 b/tzfile.5 index 0c907bc..2e88763 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -145,7 +145,7 @@ POSIX-TZ-environment-variable-style string for use in handling instants after the last transition time stored in the file (with nothing between the newlines if there is no POSIX representation for such instants). -The POSIX-style string must must agree with the local time type after +The POSIX-style string must agree with the local time type after both data's last transition times; for example, given the string .q "WET0WEST,M3.5.0,M10.5.0/3" then if a last transition time is in July, the transition's local time -- 2.9.3

1 0

[tz-announce] 2017b release of tz code and data available
by Paul Eggert March 23, 2017

March 23, 2017

The 2017b 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: Haiti has resumed DST. Changes to past and future time stamps Haiti resumed observance of DST in 2017. (Thanks to Steffen Thorsen.) Changes to past time stamps Liberia changed from -004430 to +00 on 1972-01-07, not 1972-05-01. Use "MMT" to abbreviate Liberia's time zone before 1972, as "-004430" is one byte over the POSIX limit. (Problem reported by Derick Rethans.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2017b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2017b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2017b.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 f8ebe3a644e12b294dfc3c06c5243c1b9c13a7e8 dated 2017-03-17 07:30:38 -0700 and tagged '2017b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 9a73af4b868506d1f6287a8285dea489e68f6828da19509114f9144e2a2019c7fd28f4fb98ea907030d11d011ce3a87d99dbe43bca218beddafff151f0d61df1 tzcode2017b.tar.gz 3e090dba1f52e4c63b4930b28f4bf38b56aabd6728f23094cb5801d10f4e464f17231f17b75b8866714bf98199c166ea840de0787b75b2274aa419a4e14bbc4d tzdata2017b.tar.gz 5003caab927eccf1d8f13391f4658733b3cfa05be1fcc99e0ab127ef6673514239d906677ab9b64f51777d450262d1db1868647b6afa868ab0ef93dcc8934db3 tzdb-2017b.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYy/QVAAoJEO2X6Q5iqn40h2cQAJhVT8aErVfu5cdjXIHn97Zr igIlZT+Q+xF5lu8cZxcW6j9bUZ9TG3PVcCnT6ujGtMr4UiTsiPeCmNXmGwtPmMez ZNloo3CBO+kaFFVCijEeNqN3ouXEMdlkfDtbdKKQ3AobQejowu+G2E9Qhmb4rjDj M5naQ+42nmB0mM1j1n4tyc6jL70gRaqSMmTUxVH4B69/GyD4Og4nuM1anfDfq26t dzhesg4q6TrdO5JJUHObH1FAYH95ZxzgVZ5jkT5N4Txl9UukpxI8u49nDfac9QeO RlvKaXcR7WQgC5fNxqvF5DKBzGmnZI4gx4CJMa+7IsjssOTsVmH1nYXsUdgR4kCf x7zH6s0buLICDRCKPr3pep/IYxj2DXYRBT5ViqMlQf3A3wGIgRUF6EPMKI1vfppv fXjdixU4HsZiJS7Epe6kcezcJrZ8n1YWEQxjFe8qYEJs08mApsSC5DGBXcBchLQI 2S6Au6d6fwqO77K7eOgj8MbYjC/Orhz8dIUGtjAjeZ/qek9ON32l0rPt2QxSnODc 43qtY2H7Uvky45J2niyOEnRbSKLSr5NZPdng4pmp376iVCGTisHJlwtRRfdfPGQo 56LUq4x3UaM3zVDHcpCLHvc7VQKYt3uVVzxbf89PN3jHZ459EqpOtM2TJIHtniw+ 8Ytju9WAEg4OscZi6VnF =B5DX -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYy/QVAAoJEO2X6Q5iqn40JJkP/2GuKex77gS9RXlx5iDbW+3x CAz6HEIcNGW2jEZCIM0zdvHH2Rw27/5CGixWWFGW4JWIQRu3Jtma4aCE++XUtYl0 +xHrnm43BmiYNUq7lNQsoGwLYTNMxvlOkk6vMBVRRQvODQGajdSgYC/D0Oc3VGG5 6X5ofl+vTyOpsDtGLtsJcqaaqE5hPf3rUfGWuEDVuwpoiKAckMoB4sNufOsf0DTT iNogrYCnGKLd4SM08xkPY56qipEONYh5u/4lZfcUCPkqtZmp3j3EVzuHS365aTwP 0jhSqTmAlCC7wL1eOQPY4Lot4WebSsdqVGqCfZCpwRfke39FCFCPHyZI8RwbIgRR gxNPV0U5V4FpjTXx1mVjv3m5ibp+4FetCKFvbtX5AKMikaGqujouOlKup899owH2 pFPQ/5O4fJGee51LQQRirnXSYftSplnu7Qz0ti2b43OIVq0JFyqkVCevoSRf1LqZ QXaDQtaVR2Vfm4p2yVD2hBwhpr/ZvTDLRAaynT8eZ1C8DUASAGA/LsplQ62x1mIO inGrNsuIs7MsSy4RAk/VruVnDeUZNnEAYE53dQB0uJHbFNo4FyOu6stp9JNy7k8X 98AuiLdnSPDmCJs69w8BqePcVxnNMgDcHbsDwaPGl/WcDEhLGFkSsHfp02QVTo1L Yi+G86lCBaDMrp4I7g5J =5tCY -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYy/QVAAoJEO2X6Q5iqn40DxIQALEkQyPnAC3PCu10cf1+wPDh vEu8fkMbZ47klCgPbj+ZdtPWRASFc+9BJcE3KiRyxgCYPnMr7XfBlXgq1bPVsl+X h3RJXsQdh8N6hGkL4hPCQ/t+/5SNfFmHudDV71KjaGpERDyAdz2/D7cPY5nGe4r6 hr7SWPO3QXzpnY7qVW7ZCifE/XEr75o5/h9xyIPJanLLltwxE/XTLlwr4yBM91Yt PMQv0bJbyZ+l13QF1P/Rtt7gsOqWuxyNuH+lyPDOC/XN3YG0sTjt8QmpM+svo863 aZVqzjdfnJ7BkQNICc9W5WShXhK6bQNk/lvRinOwXgwzY2tYeqx+jdi2AqEWJK4c xRfUDOePyrDG731oIBKb2J4p1nKuw4MZ1G5RVIHVTk6xf7QL9+1MwRLpxb/o9fOl Vt+T1RZL2v12rLu0/orokeYR3mAsme73k4zBmQODDLXkD2j4GtRLqXroTB1+3y+X njmJRIB7N2SdKx1Kvn2QOkpn+FKpJatMg1B64qGbPgVM0Cf359tHu0G0eRP2SLgI 2e0buF88i3oj9sYJ4d4Nc11qc9W4MQ8qhVG0z9rqFeMronJ5RQoBwM1OkW5ew4Ei /4QWijN0P82fAFwfHUxCzqqLrKmbVSmW80bk9o5EsX1LTOUK4UVJuYazcpIXTj7B ThCKSUwrWbJF62oTuL71 =FavL -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

2017b announcement?
by Joachim Sauer March 21, 2017

March 21, 2017

Hello, I see that the 2017b update is available for download, but I don't see an announcement in the tz-announce archive. Am I missing something? cheers Joachim

2 1

When did the subdirectory decision get made?
by Matthew Donadio March 19, 2017

March 19, 2017

The northamerica file has this note in it: # From Paul Eggert (2007-08-17): # ... # Other than Indianapolis, the Indiana place names are so nondescript # that they would be ambiguous if we left them at the 'America' level. # So we reluctantly put them all in a subdirectory 'America/Indiana'. I have gone through the mailing list archives from around this time, and also the 8/2005 timeframe (when the Indiana changes were starting to become clear), but I can't find any discussion about this, and Google is failing me. Does anyone remember when the pros and cons of using three levels for names was discussed? I just want to read up on some of that background. Thanks. --Matthew Donadio (matt(a)mxd120.com)

2 1

[PROPOSED] Richard Feynman and Mel Blanc collaborated
by Paul Eggert March 19, 2017

March 19, 2017

* tz-art.htm (Documentaries): Mention Feynman and Blanc. --- tz-art.htm | 1 + 1 file changed, 1 insertion(+) diff --git a/tz-art.htm b/tz-art.htm index 4892412..f726cce 100644 --- a/tz-art.htm +++ b/tz-art.htm @@ -26,6 +26,7 @@ briefly says why France has more time zones than Russia.</a> <li> "About Time" (1962; 53 minutes) is part of the the Bell Science extravaganza, with Frank Baxter, Richard Deacon, and Les Tremayne. +Its advisor was Richard Feynman, and it was voiced by Mel Blanc. (<a href="http://www.imdb.com/title/tt0154110/">IMDb entry</a>.)</li> </ul> <h2>Movies</h2> -- 2.7.4

1 0

Time Zones explained by Radio Free Europe
by Donald MacQueen March 19, 2017

March 19, 2017

All The Time In The World: Explaining The Mysteries Of Time Zones http://www.rferl.org/a/28375932.html

2 1

Palestine Summer Time
by Sharef Mustafa March 19, 2017

March 19, 2017

Hi, Palestine summer time will start on Mar 25th 2017 as per many local news agencies which published the news of the Palestinian cabinet meeting of March 14th which included the government decision of starting the summer time on Mar 25th 2017. However the decree it self is still not uploaded on the cabinet website, also the exact time of the shift was not mentioned, this affects Asia/Gaza & Asia/Hebron time zones, please find below links to some news sites (in Arabic) https://www.maannews.net/Content.aspx?id=897248 https://www.alwatanvoice.com/arabic/news/2017/03/14/1028254.html http://www.arn.ps/archives/194854 http://www.palsawa.com/news/2017/03/14/main/107123.html http://www.rmix.ps/archives/84243 unfortunately I did not find an English resource Regards. Sharef Mustafa

2 1

Why the Ancient Britons did not use Daylight Saving Time
by Jonathan Leffler March 17, 2017

March 17, 2017

http://www.gocomics.com/nonsequitur/2017/03/12 -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

2 1

mktime(): wrong value for DST taken?
by Kees Dekker March 14, 2017

March 14, 2017

Hi, Not sure whether it is related to mktime (see also http://mm.icann.org/pipermail/tz/2017-January/thread.html#24749) but I run into a similar issue. Consider the code below, and compile with (any) tz library (I tried with 2017A code). Save the source and compile with: gcc -o <out> <source> -L <tzdir> -ltz Running the produced exe results in: gcc -o ambigioustest2017a ambigioustest.c -L./tzcode2017a/ -ltz kdekker@nlbavlsm3.infor.com:/home/kdekker/downloads$ ./ambigioustest2017a enter mktime with: 1970/Jan/15278 00:119:30, week day: -858993460, year day: -858993460, dst: -1 the return value of mktime is: 1319957970 normalized times: 2011/Oct/30 01:59:30, week day: Sun, year day: 302, dst: 0 tz=EST, EDT Based on the provided TZ value, I expected that 01:59:30 is still in DST, and thus the returned value by mktime should be 1319954370 (i.e. one hour off). What I'm doing wrong, or what is wrong in the mktime() code? Please not that running the same source by using the built-in glibc mktime() function (i.e. gcc -o <exe> <sourcefile> and no additional flags), the result changes to: enter mktime with: 1970/Jan/15278 00:119:30, week day: -858993460, year day: -858993460, dst: -1 the return value of mktime is: 1319954370 normalized times: 2011/Oct/30 01:59:30, week day: Sun, year day: 302, dst: 1 tz=EST, EDT Note the minor differences with the previous output. Please let me know what should be correct? The provided source code is a part of our larger own test suite. Our test suite tests a wide range of values, especially near boundaries or ambiguous values. Regards, Kees /* start C-code */ #include <time.h> #include <stdio.h> int main(void) { int ret = 0; const char *months[] = { "Jan", "Feb", "Mar", "April", "May", "June", "July", "Aug", "Sep", "Oct", "Nov", "Dec" }; const char *days[] = { "Sun", "Mon", "Tue", "Wed", "Tur", "Fri", "Sat" }; // Back from daylight saving time to normal time. // In 2011, this happened October 30. // At 03:00 hours, local time was set back one hour. // So local time interval 02:00 - 03:00 hours is ambiguous: // It exists both in dayligth saving time and in normal time. putenv("TZ=EST5EDT,M4.1.0/02:00,M10.5.0/02:00"); struct tm tmp = { 30, 119, 0, 15278, 0, 70, -858993460, -858993460, -1}; printf("enter mktime with: %04d/%s/%02d %02d:%02d:%02d, week day: %d, year day: %d, dst: %d\n", tmp.tm_year + 1900, months[tmp.tm_mon], tmp.tm_mday, tmp.tm_hour, tmp.tm_min, tmp.tm_sec, tmp.tm_wday, tmp.tm_yday, tmp.tm_isdst); time_t t = mktime(&tmp); /* expect: t == 1319954370, DST is still on, because it still some seconds before 2:00 */ printf("the return value of mktime is: %lld\n", (long long)t); printf("normalized times: %04d/%s/%02d %02d:%02d:%02d, week day: %s, year day: %d, dst: %d\n", tmp.tm_year + 1900, months[tmp.tm_mon], tmp.tm_mday, tmp.tm_hour, tmp.tm_min, tmp.tm_sec, days[tmp.tm_wday], tmp.tm_yday, tmp.tm_isdst); if (t >= 0) { printf("tz=%s, %s\n", tzname[0], tzname[1]); } return 0; } /* End-of-C-Code */

2 1

Re: [tz] question about mktime_tzname()
by Kees Dekker March 14, 2017

March 14, 2017

Hi, Can anyone help me? In short, I set TZ to EST5EDT,M4.1.0/02:00,M10.5.0/02:00, which means daylight saving for EST (=GMT-5 or GMT-4 if DST is active), with switching DST at first Sunday of April and move to standard time at the last Sunday of October. The input to mktime is (See also attached source code) 1-1-1970, 19:00h (tm_min=1140 = 1140/60 = 19h) local EST time and tm_isdst set to -1. Because of this value, the tz code should figure out that 1-1-1970 is not in DST so the time difference with GMT/UTC is 5 hours. I would exect then mktime() to return 0. This is true if I use the system functions, but mktime() returns -3600 when using the tz library. The output of running the test case with system libraries is: ./tztestcase enter mktime with: 1970/Jan/00 00:1140:00, week day: -858993460, year day: -858993460, dst: -1 the return value of mktime is: 0 normalized times: 1969/Dec/31 19:00:00, week day: Wed, year day: 364, dst: 0 The output of the test case with the tz lib is: ./tztestcase2016j enter mktime with: 1970/Jan/00 00:1140:00, week day: -858993460, year day: -858993460, dst: -1 the return value of mktime is: -3600 normalized times: 1969/Dec/31 19:00:00, week day: Wed, year day: 364, dst: 1 Please correct me if I'm wrong. Is this a bug in the tz code? Please note the differences. From: Kees Dekker Sent: Thursday, January 05, 2017 15:03 To: 'tz(a)iana.org' <tz(a)iana.org> Subject: question about mktime_tzname() Hi, I'm running into a potential bug. Please also see the attached C-source file for a reproduction. Reproduction steps: 1. Build tz code, in such way that a libtz.a exists 2. Compile attached source with (e.g. on Linux): gcc -g -o tztestcase2016j tztestcase.c -L <tzlibdir> -ltz 3. Checking the same test case source code with a system library (instead of IANA libtz.a) can be achieved by omitting -L and -l flags in previous command (see #2). It does not make much sense which version of tzcode is used, I tried 2013i and 2016j and both show the same behavior. The mktime() code returns -3600, while I expect 0. Because the TZ zone is explicitly specified, EST5EDT is GMT-5. So the provided time stamp (31-Jan-1969, 19:00) is exactly the same as UTC value 0 (1-Jan-1970, 00:00 GMT). Both Linux and Windows with system libraries return 0 in this specific case (I used these for reference). The remainder of this email is based on the tzcode2016j source code (e.g. for used line numbers). The provided TZ value is parsed in tzparse() and results in sp->ttis[0] set as DST value, and sp->ttis[1] as standard time value. This is at least contrary to in the else part of the if (*name == ',' || *name == ';') block (there DST is saved in sp->ttis[1]). Just grep on init_ttinfo() calls in localtime.c. However, in localsub(), around line 1428, the i becomes sp->defaulttype (which is zero), i.e. points to the DST value of sp->ttis[], which is assigned to ttisp. As result, because t is below sp->ats[0], DST takes into effect, which is incorrect, as everything after the last Sunday in October and before the first Sunday in April (see attachment, TZ="EST5EDT,M4.1.0/02:00,M10.5.0/02:00") is assumed to be standard time. I'm not sure whether I draw the right conclusion, but because the incorrect assumption of using DST, mktime() returns -3600 (on hour off) instead of the expected 0. Is this conclusion correct? I'm not sure how to fix it. When changing the call to init_ttinfo() and effectively swapping DST and standard time (also for symmetry with the else part) in sp-ttis[] (0 to 1 and 1 to 0) + keeping sp->defaulttype = 0 solved this problem, but introduces other conversion errors around DSTchanges (I don't have yet an reproduction, but can make one if needed). The sp->default type is used (in localsub ()) when if (sp->timecnt == 0 || t < sp->ats[0]). The other approach is to assign sp->defaulttype = 1 when the init_ttinfo() calls are not swapped. Anyhow, there is a tight relationship between the value of sp->defaulttype and the order in which DST/standard times are written in sp->ttis[]. If the previous idea is incorrect (and I guess it is), additional code may be needed in time2sub() if yourtm.tm_isdst == -1. In that case, the provided data in yourtm should be checked whether DST is (or is not) into effect. The found mytm struct should match. Otherwise a DST correction is needed (one-hour shift). The current code mistakenly uses DST, and that is why (if I understand all well) mktime() now returns -3600. If I was not able to explain the issue correctly, please let me know. I'm not sure to understand what's going wrong now, but may be, the provided attachment will help in giving better understanding. Because the provided date is near 1970, quite few steps are needed to see what's happing in localtime.c. Regards, Kees Dekker PS. This email has been sent assuming that attachments will not get lost. Otherwise, just copy paste the code below and save to e.g. tztestcase.c. #ifdef _WIN32 #define _CRT_SECURE_NO_WARNINGS #endif #include <time.h> #include <stdio.h> #include <stdlib.h> int main(void) { int ret = 0; const char *months[] = { "Jan", "Feb", "Mar", "April", "May", "June", "July", "Aug", "Sep", "Oct", "Nov", "Dec" }; const char *days[] = { "Sun", "Mon", "Tue", "Wed", "Tur", "Fri", "Sat" }; /* DST switch in April in first Sunday and October, last Sunday */ putenv("TZ=EST5EDT,M4.1.0/02:00,M10.5.0/02:00"); /* January, 1970, invalid input for tm_mday (0 instead 1..31) */ /* non-normalized input for minutes: 1140/60 = 19, so 19:00 EST5EDT time, which is 5 hours before GMT, and should result in t == 0 below */ /* let system figure out whether DST is effect */ struct tm tmp = { 0, 1140, 0, 0, 0, 70, -858993460, -858993460, -1}; printf("enter mktime with: %04d/%s/%02d %02d:%02d:%02d, week day: %d, year day: %d, dst: %d\n", tmp.tm_year + 1900, months[tmp.tm_mon], tmp.tm_mday, tmp.tm_hour, tmp.tm_min, tmp.tm_sec, tmp.tm_wday, tmp.tm_yday, tmp.tm_isdst); time_t t = mktime(&tmp); /* expect: t == 0, DST is off, time is exactly at the boundary of lowest possible UTC value */ printf("the return value of mktime is: %lld\n", (long long)t); printf("normalized times: %04d/%s/%02d %02d:%02d:%02d, week day: %s, year day: %d, dst: %d\n", tmp.tm_year + 1900, months[tmp.tm_mon], tmp.tm_mday, tmp.tm_hour, tmp.tm_min, tmp.tm_sec, days[tmp.tm_wday], tmp.tm_yday, tmp.tm_isdst); if (t >= 0) { printf("tz=%s, %s\n", tzname[0], tzname[1]); } return 0; }

5 26

Re: [tz] State of Texas – A plan to end daylight saving time
by Steve Jones March 14, 2017

March 14, 2017

Folks: I've closely followed a few specific legislative topics in North America for many years, adding time zone to the list a few years ago. It seems to me that the body of legislation proposed to impact time zone or DST follows the general tendency to have no chance of ever coming to a vote, much less passing. In the US Congress only about one out of 20 bills is passed. I can't cite a similar statistic for state legislatures, but believe the phenomena is even more pronounced at the state level. The vast majority of bills are trial balloons, vanity projects, Quixotic, shots across some bow or another, or just plain crazy. So for no reason other than statistics I doubt this bill will go anywhere, though it is hard to know when we are hearing about a rare bill with "legs" — unless someone with specific inside knowledge shares it with the list. The only legislation I can imagine could ever achieve broad public support would be to abolish DST altogether at the national level, and even that is a long shot. Regards, Steve Jones

2 1

State of Texas – A plan to end daylight saving time
by Vance, Frank March 13, 2017

March 13, 2017

‘ “It’s really time to end this archaic practice of springing forward,” said Rep. Jason Isaac, R-Dripping Springs. And he has a plan. Isaac filed legislation to exempt Texas from daylight saving time.’ http://kxan.com/2017/03/11/state-of-texas-a-plan-to-end-daylight-saving-tim… Regards, F

4 4

NYTimes, New England Atlantic Time
by Steve Allen March 13, 2017

March 13, 2017

NY Times has noticed the New Englanders talking about moving to Atlantic time https://www.nytimes.com/2017/03/12/us/spring-forward-daylight-savings-time.… -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

1 0

Africa - Monrovia - 2017a
by Colin Ashley March 12, 2017

March 12, 2017

Hi, Please could I report a warning seen during ‘zic’ on the 2017 africa timezone file. The offset on line 434 for Monrovia is -004433 which causes the following message: warning: "africa", line 434: time zone abbreviation has too many characters (-004430) Thanks and regards Colin Ashley Actian Corporation

2 1

Haiti on DST again
by Steffen Thorsen March 12, 2017

March 12, 2017

We have received 4 mails from different people telling that Haiti has started DST again today, and this source seems to confirm that, I have not been able to find a more authoritative source: https://www.haitilibre.com/en/news-20319-haiti-notices-time-change-in-haiti… Best regards, Steffen Thorsen - timeanddate.com

2 1

Regarding mktime issue
by Gopesh Kumar Chaudhary March 9, 2017

March 9, 2017

Hello Everyone, This is Gopesh Kumar Chaudhary from India. I have couple of queries regarding mktime function. e.g. TZ=Europe/Berlin (Olson) struct tm prnt_time; prnt_time.tm_wday = 0; prnt_time.tm_mon = 10 - 1; prnt_time.tm_mday = 30; prnt_time.tm_hour = 2; prnt_time.tm_min = 0; prnt_time.tm_sec = 0; prnt_time.tm_year = 116; prnt_time.tm_isdst = -1; Above tm structure represent 30th OCT 2:30 2016 for Europe/Berlin in Olson . For Europe/Berlin DST fallback will happen on 30th Oct at 3 , so clock will show 2 to 3 time period twice. I have set the dst flag to -1 , for mktime to decide whether the given time in tm structure is DST time or non DST time. Now coming to my query : 1) In above mentioned scenario does mktime has the intelligence to decide whether above mentioned time in tm structure is in DST or not as dst flag is set to -1 ? 2) I have a sample code Sample code :- ----------------------- # cat gops.c #include<stdio.h> #include<time.h> int main(int argc,char **argv){ struct tm *at; time_t when,now; now=atoi(argv[1]); at=localtime(&now); at->tm_isdst = -1; when=mktime(at); printf("now=%d when=%d\n",now,when); return 0; } OS: Linux (RHEL 7.2) Platform:x86 TZ:Europe/Berlin (Olson) # ./gops 1477787940 ==============>This epoch is for 2:39 30th Oct 2016 DST now=1477787940 when=1477791540 ====>Here mktime is giving me the epoch for 2:39 30th Oct 2016 non-DST # ./gops 1477791540 ==============>This epoch is for 2:39 30th Oct 2016 non DST now=1477791540 when=1477791540 ====>Here mktime is giving me the epoch for 2:39 30th Oct 2016 non-DST With the above example it can be seen that irrespective of the DST/non-DST window , it is always giving non DST epoch only ---- Is this standard behavior or is this bug in mktime ? Thanks. Regards, Gopesh Kumar Chaudhary

2 3

USNO web site down
by Arthur David Olson March 9, 2017

March 9, 2017

Just in time for this weekend's winter forward in the US, as noted by Neal Augenstein on Twitter: "Hmph, wanna see when spring starts? US Naval Observatory site and master clock are down." https://twitter.com/AugensteinWTOP/status/839900149375774720 http://www.usno.navy.mil/USNO/time/display-clocks/simpletime @dashdashado

2 1

Re: [tz] tz abbr too long in 2017a Africa/Monrovia [was: zic throws warning for 2007a]
by Brian Inglis March 2, 2017

March 2, 2017

On 2017-03-02 18:47, Jonathan Leffler wrote: > On Wed, Mar 1, 2017 at 2:16 PM, Brian Inglis wrote: >On 2017-03-01 14:48, Tim Parenti wrote: >> On 1 March 2017 at 16:42, Brian Inglis wrote: >> Looks like it stores the over long abbreviation. >> So should probably patch: >> --- tz/releases/tzdata2017a/africa 2017-02-23 00:37:19.000000000 -0700 >> +++ tz/releases/tzdata2017b/africa 2017-03-01 14:36:43.479882200 -0700 >> @@ -431,7 +431,7 @@ Link Africa/Nairobi Indian/Mayotte >> # Zone NAME GMTOFF RULES FORMAT [UNTIL] >> Zone Africa/Monrovia -0:43:08 - LMT 1882 >> -0:43:08 - MMT 1919 Mar # Monrovia Mean Time >> - -0:44:30 - -004430 1972 May >> + -0:44:30 - -0044 1972 May >> 0:00 - GMT >> The above patch would be incorrect, though. It would be more correct >> to increase the allowed max abbreviation length. (Even better, >> numerical "abbreviations" like this should just be exempted from the >> caps, since they can technically be of almost any length, even though >> this is the longest they'll be in practice.) >POSIX limit in limits.h: >http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag… >under TZ definition for std and dst (abbrs) >"The interpretation of these fields is unspecified if either field is >less than three bytes (except for the case when dst is missing), more >than {TZNAME_MAX} bytes, or if they contain characters other than those >specified." >http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html#tag_… >"{_POSIX_TZNAME_MAX} >Maximum number of bytes supported for the name of a timezone (not of >the TZ variable). >Value: 6" > Note that the spiel above the entry for {_POSIX_TZNAME_MAX} says: > The /<limits.h>/ header shall define the following symbolic constants > with the values shown. These are the most restrictive values for > certain features on an implementation conforming to this volume of > POSIX.1-2008. Related symbolic constants are defined elsewhere in > this volume of POSIX.1-2008 which reflect the actual implementation > and which need not be as restrictive. For each of these limits, a > conforming implementation shall provide a value at least this large > or shall have no limit. A strictly conforming application must not > require a larger value for correct operation. > Is the code in tzcode intended to be a strictly conforming > application? From: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag… the application is not a Strictly Conforming POSIX Application as it does not #define _POSIX_C_SOURCE 200809L, and is not a Conforming POSIX Application as it does not include a "statement of conformance that documents all options and limit dependencies, and all other ISO or IEC standards used", although commentary indicates POSIX compliance where notable. AFAICT like many packages, it is intended to be POSIX compliant and provide POSIX compliant implementations, to be portable to POSIX compliant and some non-POSIX systems. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

1 0

Problem with historical Asia/Manila?
by Paul Goyette March 2, 2017

March 2, 2017

According to the asia file, the Philippines jumped 24 hours on May 11, 1899, from -15:56:00 to +8:04:00 (they moved the international date line?) # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Manila -15:56:00 - LMT 1844 Dec 31 8:04:00 - LMT 1899 May 11 8:00 Phil +08/+09 1942 May 9:00 - +09 1944 Nov 8:00 Phil +08/+09 Yet zdump shows only a 4-minute step in local time, rather than the expected 24-hour step: # zdump -c 1815,2018 -v Asia/Manila Asia/Manila -9223372036854775808 = NULL Asia/Manila -9223372036854689408 = NULL Asia/Manila Tue Dec 31 15:55:59 1844 UT = Mon Dec 30 23:59:59 1844 LMT isdst=0 gmtoff=-57360 Asia/Manila Tue Dec 31 15:56:00 1844 UT = Wed Jan 1 00:00:00 1845 LMT isdst=0 gmtoff=29040 Asia/Manila Wed May 10 15:55:59 1899 UT = Wed May 10 23:59:59 1899 LMT isdst=0 gmtoff=29040 Asia/Manila Wed May 10 15:56:00 1899 UT = Wed May 10 23:56:00 1899 +08 isdst=0 gmtoff=28800 Asia/Manila Sat Oct 31 15:59:59 1936 UT = Sat Oct 31 23:59:59 1936 +08 isdst=0 gmtoff=28800 ... Obviously a low-priority issue, since it's more than 100 years ago, but still would be nice to know why we have a problem. It's not totally out of the realm of probability that someone will move the dateline again, perhaps if the UTC+14 parts of Kiribati were to separate from the rest of the country? :) Data gathered on a NetBSD 7.99.64 system running on amd64 hardware, and using the 2017a tzdata. I think we're still running 2016i version of tzcode. So the question(s): * is zdump wrong? * is the compiled data file wrong? * (most likely) am I just misinterpreting the data? * is this something that has already been fixed in a more recent tzcode release? +------------------+--------------------------+------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +------------------+--------------------------+------------------------+

3 3

zic throws warning for 2007a
by Derick Rethans March 1, 2017

March 1, 2017

Hi, I've just updated the PHP version of the TZ database, and while compiling with the current zic, I see: warning: "standard input", line 434: time zone abbreviation has too many characters (-004430) This is because of: 24 #ifndef ZIC_MAX_ABBR_LEN_WO_WARN 25 #define ZIC_MAX_ABBR_LEN_WO_WARN 6 26 #endif /* !defined ZIC_MAX_ABBR_LEN_WO_WARN */ 3108 if (cp - string > ZIC_MAX_ABBR_LEN_WO_WARN) 3109 mp = _("time zone abbreviation has too many characters"); That check was introduced in 2012j as per NEWS: Release 2012j - 2012-11-12 18:34:49 -0800 ... zic -v now complains about abbreviations that are less than 3 or more than 6 characters, as per Posix. Formerly, it checked for abbreviations that were more than 3. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug

6 6