[tz] Regarding mktime issue

Gopesh Kumar Chaudhary kumar.ggopesh at gmail.com
Thu Mar 9 11:37:08 UTC 2017


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 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...
URL: <http://mm.icann.org/pipermail/tz/attachments/20170309/10327fb2/attachment.html>


More information about the tz mailing list