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.