Obtaining STD time on BSD/Darwin

I am in the process of porting functions from win32 to Linux/Posix and
BSD/Darwin that will return the local time adjusted for daylight saving
time and the local standard time (not adjusted).  I have learned that
Posix defines a global variable, timezone, which is set when the
tzset() function is invoked, that provides the standard time as seconds
west of Greenwich.  Unfortunately, I also learned that this is not
supported under Darwin and, I assume, under other BSD derivatives.  The
GLibC manual states that these are provided for SYSV compatibility.

My question is what can I do on the BSD derivatives to obtain the
standard (not adjusted for daylight savings time) offset?  Does this
involve reading the /etc/localtime file or is there an easier way that
I have entirely overlooked?

Regards,

Jon Trauntvein

"JH Trauntvein" <j.trauntvein@comcast.net> writes:

> I am in the process of porting functions from win32 to Linux/Posix and
> BSD/Darwin that will return the local time adjusted for daylight saving
> time and the local standard time (not adjusted).

This is redundant.  On UNIX the adjustments are done for you.

> I have learned that Posix defines a global variable, timezone, which
> is set when the tzset() function is invoked, that provides the
> standard time as seconds west of Greenwich.  Unfortunately, I also
> learned that this is not supported under Darwin and, I assume, under
> other BSD derivatives.  The GLibC manual states that these are
> provided for SYSV compatibility.

"This function is automatically called by the other time conversion
functions that depend on the time zone." [tzset(3)].  You can probably
ignore it.

> My question is what can I do on the BSD derivatives to obtain the
> standard (not adjusted for daylight savings time) offset?  Does this
> involve reading the /etc/localtime file or is there an easier way that
> I have entirely overlooked?

It's all automatically taken care of by the C library.  See ctime(3);
you want gmtime[_r] and localtime[_r].


--
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linux        http://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Roger Leigh wrote:
> "JH Trauntvein" <j.trauntvein@comcast.net> writes:
> 
and 
saving 
>
> This is redundant.  On UNIX the adjustments are done for you.
> 
which 
under 
>
> "This function is automatically called by the other time conversion
> functions that depend on the time zone." [tzset(3)].  You can
probably
> ignore it.
> 
this 
that 
>
> It's all automatically taken care of by the C library.  See ctime(3);
> you want gmtime[_r] and localtime[_r].

Yes, localtime[_r] will return the corrected time WITH daylight savings
time built in.  However, one of my functions needs to return the local
time WITHOUT daylight savings time or, in other words, the local
standard time.  To do this, I need to know the bias that the OS applies
to adjust for daylight time.

Also, according to the docs that I have read, tzset() is not guaranteed
to be called by the re-entrant version (see
http://www.opengroup.org/onlinepubs.../localtime.html for
more details about this).

Regards,

Jon Trauntvein

"JH Trauntvein" <j.trauntvein@comcast.net> writes:

> localtime[_r] will return the corrected time WITH daylight savings
> time built in.  However, one of my functions needs to return the
> local time WITHOUT daylight savings time or, in other words, the
> local standard time.  To do this, I need to know the bias that the
> OS applies to adjust for daylight time.

Sorry, my mistake.  I can't see a portable way of doing this, though
one possibility would be to make a "struct tm" for four equally spaced
months in the year, and check tm_isdst and tm_gmtoff to compute the
offset by hand (at least one will have a different offset, since the
offset includes daylight savings).

(This might only be portable to GNU/Linux and BSD systems, though.)


Regards,
Roger

--
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linux        http://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Roger Leigh wrote:
> "JH Trauntvein" <j.trauntvein@comcast.net> writes:
>
> 
>
>
> Sorry, my mistake.  I can't see a portable way of doing this, though
> one possibility would be to make a "struct tm" for four equally spaced
> months in the year, and check tm_isdst and tm_gmtoff to compute the
> offset by hand (at least one will have a different offset, since the
> offset includes daylight savings).
>
> (This might only be portable to GNU/Linux and BSD systems, though.)

Taking the approach a step further, how about (error
checking omitted):

time_t when = time(NULL);
struct tm bdt = *localtime(&when);
if (bdt.tm_isdst == 1) {
struct tm xxx = bdt;
xxx.tm_isdst = 0;
bdt.tm_sec -= mktime(&xxx) - when;
mktime (&bdt);  /* to "normalize" */
}
printf ("Given:\t%s", ctime(&when));
printf ("Result:\t%s", asctime(&bdt));

--
Eric.Sosman@sun.com

Eric Sosman wrote:
> Roger Leigh wrote: 
though 
spaced 
the 
>
>     Taking the approach a step further, how about (error
> checking omitted):
>
> 	time_t when = time(NULL);
> 	struct tm bdt = *localtime(&when);
> 	if (bdt.tm_isdst == 1) {
> 	    struct tm xxx = bdt;
> 	    xxx.tm_isdst = 0;
> 	    bdt.tm_sec -= mktime(&xxx) - when;
> 	    mktime (&bdt);  /* to "normalize" */
> 	}
> 	printf ("Given:\t%s", ctime(&when));
> 	printf ("Result:\t%s", asctime(&bdt));


I thank both of you for your very good answers.  I will certainly try
them and see what comes out.

Regards,

Jon Trauntvein

Roger Leigh wrote:
> "JH Trauntvein" <j.trauntvein@comcast.net> writes:
> 
>
> Sorry, my mistake.  I can't see a portable way of doing this, though
> one possibility would be to make a "struct tm" for four equally
spaced
> months in the year, and check tm_isdst and tm_gmtoff to compute the
> offset by hand (at least one will have a different offset, since the
> offset includes daylight savings).
>
> (This might only be portable to GNU/Linux and BSD systems, though.)


This sounds like a very good idea.  I was wondering why it it would not
be sufficient to use mktime() to construct two times in the current
year, one for around the winter solstice and the other for around the
summer soltice.  My ignorance may be showing here but surely, daylight
savings time would be enabled/disabled by these dates for any locale.

Regards,

Jon Trauntvein

In article <1114610335.256512.119890@o13g2000cwo.googlegroups.com>,
"JH Trauntvein" <j.trauntvein@comcast.net> writes:
> 

> This sounds like a very good idea.  I was wondering why it it would not
> be sufficient to use mktime() to construct two times in the current
> year, one for around the winter solstice and the other for around the
> summer soltice.  My ignorance may be showing here but surely, daylight
> savings time would be enabled/disabled by these dates for any locale.

Ha! There are two things you don't seem to be aware of:

1) The idiocy of "daylight saving time" has not permeated to every corner
of the globe. My neighboring state (Indiana, USA) is one of the last hold-
outs against the insanity. Their Congress is even now debating jumping off
the cliff with the rest of the lemmings, so we'll see.

2) If mandating the Sun stay up an extra hour in the Summer is good, why
not in the Winter, when we really need it?  In 1973, the USA had daylight
saving time *all* *year* *round*, and the current US Congress is leaning
toward doing that again.

--
Frederick