- tz - lists.iana.org

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 3, 2017

March 3, 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