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
On 03/07/2017 10:45 PM, Gopesh Kumar Chaudhary wrote:
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 ?
In the example you gave, mktime can return either a timestamp with tm_isdst==0, or a timestamp with tm_isdst>0. Both answers are correct, in the sense that the relevant standards allow mktime to return either answer. So the RHEL 7.2 mktime is operating correctly. In general, the output of localtime is ambiguous, in the sense that two different timestamps can generate exactly the same struct tm values on some platforms, and POSIX allows this. An example of that is the repeated time 2014-10-26 01:30 when TZ="Europe/Moscow", which corresponds to both 1414276200 and to 1414279800 when considered as POSIX timestamps. This is because Moscow changed timezones from UT +04 to +03 that morning.
Hello Paul, As you said mktime can return either one timestamp with tm_isdst==0, or a timestamp with tm_isdst>0 and both are correct . The thing is mktime returns the epoch for the tm structure which we have passed as input to mktime and also set the isdst flag to 0 or >0 of the passed tm structure. In linux , I am seeing that for DST 2:30 and non DST 2:30 for Europe/Berlin, it is giving the same epoch (the non DST epoch , the same behavior exist for other time zone also ) . Is it expected behavior of mktime to give non DST epoch for both DST and non DST time stamp ? I am just trying to understand the standard behavior of mktime with respect to epoch which it returns . Whether it is designed to give always non DST epoch for both DST and non DST time stamp OR it can give either of them . In case if it gives either of them then on what basis it decides which epoch is correct and that should be returned . I am just trying to understand the logic behind the epoch calculation ,how it decides which epoch is correct and that should be returned . Thanks, Gopesh On Thu, Mar 9, 2017 at 7:32 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 03/07/2017 10:45 PM, Gopesh Kumar Chaudhary wrote:
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 ?
In the example you gave, mktime can return either a timestamp with tm_isdst==0, or a timestamp with tm_isdst>0. Both answers are correct, in the sense that the relevant standards allow mktime to return either answer. So the RHEL 7.2 mktime is operating correctly.
In general, the output of localtime is ambiguous, in the sense that two different timestamps can generate exactly the same struct tm values on some platforms, and POSIX allows this. An example of that is the repeated time 2014-10-26 01:30 when TZ="Europe/Moscow", which corresponds to both 1414276200 and to 1414279800 when considered as POSIX timestamps. This is because Moscow changed timezones from UT +04 to +03 that morning.
On 03/09/2017 03:37 AM, Gopesh Kumar Chaudhary wrote:
Is it expected behavior of mktime to give non DST epoch for both DST and non DST time stamp ?
If you give mktime a valid struct tm whose tm_isdst value is positive and mktime returns successfully, the resulting tm_isdst should also be positive. Likewise for when tm_isdst is zero. The test case you supplied, however, had a negative tm_isdst, and this told mktime that you didn't know whether the timestamp used DST and that it was OK for mktime to assume either DST or non-DST. In cases where multiple valid answers could be returned, the standard does not specify which answer is "correct". So GNU mktime is operating correctly here.
participants (2)
-
Gopesh Kumar Chaudhary -
Paul Eggert