David,

I really like what you have done for non-POSIX environments.

We have code that runs in blind-dubbed POSIX environments, and what we do
is to manually read /etc/init.options and set any environment variables
from there (that are not already set/overridden).    Seems like a good idea
for us to extend this to do what you are doing (derive TZ from CVT) in the
case that it isn't already set and not set in /etc/init.options doesn't set
TZ.

Of course, IBM could solve many problems with usability if they chose to.
My RFE seems like an obvious usability and simplification item, for this
and other problems with blind-dubbed environment variables in general.  I
suppose that they could also have the C library provide a "default" for TZ
(if not specified) that derives it from the CVT.

On Tue, Aug 20, 2019 at 5:20 AM David Crayford <dcrayf...@gmail.com> wrote:

> 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
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to