If I may ask, why are you attempting to make timezone adjustments if your
time source from the non-QNX system is also in UTC, as the system clock is?
In my opinion the tricky thing about daylight savings time is that while you
can always derive the correct local time from the UTC time using
localtime(), you cannot always derive the correct UTC time from the local
time UNLESS you also specify explictly to mktime() whether the local time is
in daylight or standard time i.e. you have to know in advance. Enter the
tm_isdst field of a struct tm. Most of the time during the year, mktime()
could calculate the correct offset for you since the dates/times are
unambiguous (you would set tm_isdst to -1 to do this). However, every fall
for a period of two hours, this calculation isn’t possible and you’d have to
specify tm_isdst as 0 or 1 to be assured of a correct conversion.
But again, if your time source is in UTC, it’s not clear to me what you are
trying to accomplish by your adjustment prior to calling clock_settime().
If prior to the code snippet that you posted, you are doing a mktime() call
to calculate a new time_t (seconds) value, you would have to deal with the
fact that mktime() expects a local time breakdown. You could get around that
by doing something along the lines of what David suggested (i.e. setting TZ
to UTC0 prior to calling mktime(), then restoring it prior to invoking the
rtc utility). This is simple and probably the best way since it also takes
care of the regular timezone adjustment also, in addition to any possible
daylight time adjustment.
Another way would be to tell mktime() that the values you are giving it are
not daylight times (setting tm_isdst to 0). The mktime() utility will
normalize the values you give it prior to returning a time_t. So for
instance if I told it to figure out the time_t for 02:75 in the morning
today, it would adjust that to 3:15 before completing the calculation. The
same sort of hijinx apply to the tm_isdst value in combination with the
dates and times. However, I wouldn’t put absolute faith in mktime() doing
the right thing, since I know there are some bugs in the QNX 4 mktime() when
it comes to handling a few those out-of-range conditions. You’d still need
to adjust the base timezone offset yourself prior to calling mktime(), as
well.
Hope that helps a little, or at least sparks some ideas that might allow you
to figure out what’s going on.
“Steve Bull” <steven.bull@cplc.com> wrote in message
news:ai903o$7ut$1@inn.qnx.com…
I am having a problem with setting the time correctly on my system. I have
the timezone environment variable configured as follows:
TZ=est05edt04.M4.1.0/2,M10.5.0/2
I am setting our system time based on the UTC time and milliseconds
provided
by a proprietary (non-QNX) system. The following code is setting the
system
time and hardware clock time.
The UTC time is stored in lhtime.tv_sec and milliseconds in
lhtime.tv_msec.
The time is set as follows:
tzset();
lhtime.tv_sec -= timezone;
clock_settime(CLOCK_REALTIME, &lhtime);
spawnl(P_NOWAIT, “/bin/rtc”, “/bin/rtc”, “-s”, “hw”, NULL);
I thought that timezone contained the number of seconds between UTC and
the
local time, but the daylight savings time does not seem to be figured in
so
I get my system time set one hour earlier than the actual time. Is there
something that I don’t understand about tzset and the value placed in
timezone?
Any help is greatly appreciated.
Steve Bull