On 2019-08-20 1:23 AM, Paul Gilmartin wrote:
... 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)
Kirk Wolf already articulated the TZ issue very well in a previous post.
For C programs that are not dubbed as UNIX processes they are basically
naked so the POSIX rules don't apply.
I would love to rely on configuration but it's not possible in all
environments which is why I wrote the code to solve that problem for one
of our products.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
