On Mon, 19 Aug 2019 17:09:22 +0800, David Crayford wrote:
>>> ...
>>> // set the time zone offset and apply the leap second offset
>>> int64_t ldto = cvt->cvtext2->cvtldto - cvt->cvtext2->cvtlso + adjust;
>>>
>> Is this intended to be used with localtime() and strftime()? Localtime()
>
>Yes, and it works perfectly :)
>
>> ... Localtime() expects time() to have accounted for leap seconds, so they
>> should not
>> appear in TZ. An example on Linux (TZ value simulated by hand):
>> 510 $ TZ=Asia/Calcutta date; TZ=GMT-5:29:33 date
>> Sun Aug 18 21:45:02 IST 2019
>> Sun Aug 18 21:44:35 GMT 2019
>
>My code is intended to be run in environments where the TZ environment
>variable has not been set. As it works as expected I'm not sure
>that time() has accounted for leap seconds.
>
From:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16
4.16 Seconds Since the Epoch
...
the value is related to a Coordinated Universal Time name according to the
C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are
all integer types:
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
...
As represented in seconds since the Epoch, each and every day shall be
accounted for by
exactly 86400 seconds.
(I.e. seconds since the epoch, used by time() accounts for leap seconds. --
gil)
My employers briefly enabled leap seconds by setting the IBM-recommended
value in CVTLSO. Legacy code and products from vendors were so inconsistent
that they regressed to setting TOD to UTC and CVTLSO=0. IBM fixed such an
error in IEBCOPY by PTF in response to my APAR.
Have you tested in an environment where CVTLSO is nonzero?
>> ... Also, the zone name, GMT, is wrong. Correct is IST.
>
>Does IST work on z/OS?
>
If TZ is set to the correct POSIX value, "IST-5:30", rather than a crudely
synthesized value, it should.
>> What happens if a DST transition, or even a leap second, occurs between
>> such a setting of TZ and your program's formatting of current time?
>
>For our purposes we don't need to be that robust so we don't care :)
>
For general purposes, a user might want better, as non-IBM systems provide.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
