difference between localtime and TZ setting?

QNX4:
In my PC, we have a TZ setting UTC00.rtc hw in sysinit file.
But when we used time() and ctime() API to log the current date and time,
we see a 4-5 hours difference between times in file and date utility
output.

But when we had TZ setting as est, the date and time logged to file were
matching with the same API.

We tried with TZ=UTC00,and used gmtime() ,time() API to log the GMT time?

Are we missing something?

Setting TZ in your sysinit won’t guarantee TZ is set for your application.
If TZ is not set, on QNX 4 the Watcom library defaulted to Eastern Standard
Time so that would explain the discrepancy. Check the value of TZ in the
program that is using the API and track back from there. If you program runs
for any period of time you can do this easily from another shell by running
‘sin env’ as root. That will be nice also as it will show you the
environment of the parent process etc. It may be immediately obvious what’s
wrong.

“radha krishnan” <radha.nk@geind.ge.com> wrote in message
news:d0jh06$qre$1@inn.qnx.com

QNX4:
In my PC, we have a TZ setting UTC00.rtc hw in sysinit file.
But when we used time() and ctime() API to log the current date and time,
we see a 4-5 hours difference between times in file and date utility
output.

But when we had TZ setting as est, the date and time logged to file were
matching with the same API.

We tried with TZ=UTC00,and used gmtime() ,time() API to log the GMT time?

Are we missing something?

\

While printing the TZ in application, it says
TZ:UTC00
daylight:1
timezone:18000
time zone names:EST EDT
Here we can see that environment variable TZ is set to UTC, but still the
timezone names are reflecting the EST.

Also, tested that this needs to be set whenever application is run. Is
there a permanent setting?

why this setting in application need to be done? aprt from environment TZ?

Eric Johnson wrote:

Setting TZ in your sysinit won’t guarantee TZ is set for your application.
If TZ is not set, on QNX 4 the Watcom library defaulted to Eastern Standard
Time so that would explain the discrepancy. Check the value of TZ in the
program that is using the API and track back from there. If you program runs
for any period of time you can do this easily from another shell by running
‘sin env’ as root. That will be nice also as it will show you the
environment of the parent process etc. It may be immediately obvious what’s
wrong.

“radha krishnan” <> radha.nk@geind.ge.com> > wrote in message
news:d0jh06$qre$> 1@inn.qnx.com> …
QNX4:
In my PC, we have a TZ setting UTC00.rtc hw in sysinit file.
But when we used time() and ctime() API to log the current date and time,
we see a 4-5 hours difference between times in file and date utility
output.

But when we had TZ setting as est, the date and time logged to file were
matching with the same API.

We tried with TZ=UTC00,and used gmtime() ,time() API to log the GMT time?

Are we missing something?

\

TZ is just an ordinary environment variable, and is no more persistent than
any other environment variable (i.e. not). There is nothing special about it
at all. The interpretation of current system time thus varies on a process
by process basis depending on the setting of the TZ environment variable
within the context of that process.

I suspect your TZ is not what you think it is in the application. If
TZ=UTC00 is present in the application’s environment, the time zone name
would be UTC not EST EDT. How are you testing TZ?

/* timeprog.c

Build this program and from the shell, compare:

env TZ=UTC0 timeprog
env TZ=EST5EDT4 timeprog
(unset TZ && timeprog)
*/

#include <stdlib.h>
#include <stdio.h>
#include <time.h>

main()
{
char *p;
time_t t;
struct tm *mytm;

if (p=getenv(“TZ”))
printf(“TZ=%s\n”,p);
else
printf(“TZ not set\n”);

tzset();

printf(“timezone offset=%d\n”,timezone);
printf(“tzname[0]=%s tzname[1]=%s\n”,tzname[0],tzname[1]);

}



“radha krishnan” <radha.nk@geind.ge.com> wrote in message
news:d0m4e4$rbk$1@inn.qnx.com

While printing the TZ in application, it says
TZ:UTC00
daylight:1
timezone:18000
time zone names:EST EDT
Here we can see that environment variable TZ is set to UTC, but still the
timezone names are reflecting the EST.

Also, tested that this needs to be set whenever application is run. Is
there a permanent setting?

why this setting in application need to be done? aprt from environment TZ?

Eric Johnson wrote:

Setting TZ in your sysinit won’t guarantee TZ is set for your
application.
If TZ is not set, on QNX 4 the Watcom library defaulted to Eastern
Standard
Time so that would explain the discrepancy. Check the value of TZ in the
program that is using the API and track back from there. If you program
runs
for any period of time you can do this easily from another shell by
running
‘sin env’ as root. That will be nice also as it will show you the
environment of the parent process etc. It may be immediately obvious
what’s
wrong.

“radha krishnan” <> radha.nk@geind.ge.com> > wrote in message
news:d0jh06$qre$> 1@inn.qnx.com> …
QNX4:
In my PC, we have a TZ setting UTC00.rtc hw in sysinit file.
But when we used time() and ctime() API to log the current date and
time,
we see a 4-5 hours difference between times in file and date utility
output.

But when we had TZ setting as est, the date and time logged to file
were
matching with the same API.

We tried with TZ=UTC00,and used gmtime() ,time() API to log the GMT
time?

Are we missing something?








\

TZ=utc00
timezone offset:0
tzname[0]:utc tzname[1]=

This was the output of the program.
when i tried doing the same thing in my application, it says the TZ not
set.
The application consists of 2 tasks. say appmgr and log.
appmgr spawns log. log task logs to file the time and date from cmtime()
output.
The problem is that the file which the log task logs is different from the
date output by 5 hrs.

If logtask is run log seperately, then there is no issue. But if appmgr is
run then this problem occurs. Tried putting the below code in log.cc file.
It prints TZ not set.
But if appmgr passes the environment as a parameter to this task then it
is working fine.

What you said on context of process applies here appropriately.

SO, conclusion is that TZ is context dependent.and need to be set on a per
process basis. Am i right?

One more problem when the below program is being spwaned by appmgr it says
TZ not set , but when run seperately its fine.DOn’t know what is this
issue, now!

Thanks

Tried included the below statements in log.c program. looks like when
appmgr spawns log , it prints TZ not set and when log is run seperately it
logs. when explicitly TZ ebvironment is set using setenv,

Eric Johnson wrote:

TZ is just an ordinary environment variable, and is no more persistent than
any other environment variable (i.e. not). There is nothing special about it
at all. The interpretation of current system time thus varies on a process
by process basis depending on the setting of the TZ environment variable
within the context of that process.

I suspect your TZ is not what you think it is in the application. If
TZ=UTC00 is present in the application’s environment, the time zone name
would be UTC not EST EDT. How are you testing TZ?

/* timeprog.c

Build this program and from the shell, compare:

env TZ=UTC0 timeprog
env TZ=EST5EDT4 timeprog
(unset TZ && timeprog)
*/

#include <stdlib.h
#include <stdio.h
#include <time.h

main()
{
char *p;
time_t t;
struct tm *mytm;

if (p=getenv(“TZ”))
printf(“TZ=%sn”,p);
else
printf(“TZ not setn”);

tzset();

printf(“timezone offset=%dn”,timezone);
printf(“tzname[0]=%s tzname[1]=%sn”,tzname[0],tzname[1]);

}



“radha krishnan” <> radha.nk@geind.ge.com> > wrote in message
news:d0m4e4$rbk$> 1@inn.qnx.com> …
While printing the TZ in application, it says
TZ:UTC00
daylight:1
timezone:18000
time zone names:EST EDT
Here we can see that environment variable TZ is set to UTC, but still the
timezone names are reflecting the EST.

Also, tested that this needs to be set whenever application is run. Is
there a permanent setting?

why this setting in application need to be done? aprt from environment TZ?

Eric Johnson wrote:

Setting TZ in your sysinit won’t guarantee TZ is set for your
application.
If TZ is not set, on QNX 4 the Watcom library defaulted to Eastern
Standard
Time so that would explain the discrepancy. Check the value of TZ in the
program that is using the API and track back from there. If you program
runs
for any period of time you can do this easily from another shell by
running
‘sin env’ as root. That will be nice also as it will show you the
environment of the parent process etc. It may be immediately obvious
what’s
wrong.

“radha krishnan” <> radha.nk@geind.ge.com> > wrote in message
news:d0jh06$qre$> 1@inn.qnx.com> …
QNX4:
In my PC, we have a TZ setting UTC00.rtc hw in sysinit file.
But when we used time() and ctime() API to log the current date and
time,
we see a 4-5 hours difference between times in file and date utility
output.

But when we had TZ setting as est, the date and time logged to file
were
matching with the same API.

We tried with TZ=UTC00,and used gmtime() ,time() API to log the GMT
time?

Are we missing something?








\

On Wed, 09 Mar 2005 18:10:32 +0300, Eric Johnson <eric@qnx.com> wrote:

/* timeprog.c

Build this program and from the shell, compare:

env TZ=UTC0 timeprog
env TZ=EST5EDT4 timeprog
(unset TZ && timeprog)
*/

#include <stdlib.h
#include <stdio.h
#include <time.h

main()
{
char *p;
time_t t;
struct tm *mytm;

if (p=getenv(“TZ”))
printf(“TZ=%s\n”,p);
else
printf(“TZ not set\n”);

tzset();

printf(“timezone offset=%d\n”,timezone);
printf(“tzname[0]=%s tzname[1]=%s\n”,tzname[0],tzname[1]);

}
I must be missing something here…

My TZ is “MST-3MDT-4,M3.5.0/2,M10.5.0/3” and it’s set in the
/etc/config/sysinit.$NODE
When I run the above example (today, 22nd of May 2005) I get a seemingly
wrong result:
“timezone offset=-10800”
It is DST in action now, why I get “-10800” but not “-14400”?
The “date”, however, returns the correct result “MDT”.

How to get the correct offset?

Tony.

On Mon, 23 May 2005 02:03:51 +0400, Tony wrote:


}
I must be missing something here…
My TZ is “MST-3MDT-4,M3.5.0/2,M10.5.0/3” and it’s set in the
/etc/config/sysinit.$NODE
When I run the above example (today, 22nd of May 2005) I get a seemingly
wrong result:
“timezone offset=-10800”
It is DST in action now, why I get “-10800” but not “-14400”?
The “date”, however, returns the correct result “MDT”.

How to get the correct offset?

With QNX4 I seem to recall there was a known problem/bug with timezone

variables in the eastern hemisphere (offsets negative). Try specifying your
timezone variable “the other way around”, eg

TZ=“MDT-4MST-3,M10.5.0/2,M3.5.0/3”

Rob Rutherford
Ruzz Technology

Robert Rutherford wrote:

With QNX4 I seem to recall there was a known problem/bug with timezone
variables in the eastern hemisphere (offsets negative). Try specifying your
timezone variable “the other way around”, eg

That was a Watcom libc bug, and it was actually southern hemisphere,
where your daylight savings switchover month/season is backwards
(spring vs fall, in this part “M3.5.0/2,M10.5.0/3”) so the test for
being in DST is actually not simply between two values (but between
them modulo-12). It was fixed at some point (10.6?).

I must be missing something here…
My TZ is “MST-3MDT-4,M3.5.0/2,M10.5.0/3” and it’s set in the
/etc/config/sysinit.$NODE
When I run the above example (today, 22nd of May 2005) I get a
seemingly wrong result:
“timezone offset=-10800”
It is DST in action now, why I get “-10800” but not “-14400”?
The “date”, however, returns the correct result “MDT”.

The POSIX defintion of “extern long timezone” is “The external
variable timezone shall be set to the difference between, in
seconds, between Coordinated Universal Time (UTC) and local
standard time”. The key phrase there being “local standard
time”. Thus what “timezone” is is independant on whether or not
daylight savings is currently in effect, and so in your example
should always reflect “MST-3” whatever the current date.

How to get the correct offset?

Not sure what it is you want to know? The difference between now
(local) and UTC? What about this:

time_t t1,t2;
struct tm *tm;

time(&t1);
tm = gmtime(&t1);
tm->tm_isdst = -1;
t2 = mktime™;

Difference is “t1 - t2”.

$ TZ=MST-3MDT-4,M3.5.0/2,M10.5.0/3 ./tz
TZ=MST-3MDT-4,M3.5.0/2,M10.5.0/3
timezone offset=-10800
daylight=1
tzname[0]=MST tzname[1]=MDT
DIFF=-14400

On Mon, 23 May 2005 05:25:27 +0400, John Garvey <jgarvey@qnx.com> wrote:

Not sure what it is you want to know? The difference between now (local)
and UTC? What about this:

time_t t1,t2;
struct tm *tm;

time(&t1);
tm = gmtime(&t1);
tm->tm_isdst = -1;
t2 = mktime™;

Difference is “t1 - t2”.
This it it!

Thank you!

Tony.