[tz] Regarding mktime issue
Gopesh Kumar Chaudhary
kumar.ggopesh at gmail.com
Thu Mar 9 11:37:08 UTC 2017
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 .
On Thu, Mar 9, 2017 at 7:32 AM, Paul Eggert <eggert at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz