Time

I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario

I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario

More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local machine,
everything is fine. The time is display as expected and the timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario

I too am having this problem, but because I am west coast the time
difference is much larger.
I noticed that if I log in using Phindows, click on the “Localization” shelf
application, click on
each of the already highlighted items on the “Time Zone”, “Language” and
“Keyboard” tabs
(i.e. I make no changes) and then click “Apply”, the time corrects itself.

Go Figure!

raeberhardt@tantalus-systems.com
Randy Aeberhardt
Tantalus Systems.


“Mario Charest” <mcharest@nozinformatic.com> wrote in message
news:3ae074a7.17732988@inn.qnx.com

I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local machine,
everything is fine. The time is display as expected and the timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario

I think Igor saw this problem a few months ago, if he couldn’t
get it to be fixed I guess there is little point in us reporting it :wink:

I was hoping it was unrelated to Igor’s previous report.

“Randy Aeberhardt” <raeberhardt@tantalus-systems.com> wrote in message
news:9c57re$r7n$1@nntp.qnx.com

I too am having this problem, but because I am west coast the time
difference is much larger.
I noticed that if I log in using Phindows, click on the “Localization”
shelf
application, click on
each of the already highlighted items on the “Time Zone”, “Language” and
“Keyboard” tabs
(i.e. I make no changes) and then click “Apply”, the time corrects itself.

Go Figure!

raeberhardt@tantalus-systems.com
Randy Aeberhardt
Tantalus Systems.


“Mario Charest” <> mcharest@nozinformatic.com> > wrote in message
news:> 3ae074a7.17732988@inn.qnx.com> …




I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local machine,
everything is fine. The time is display as expected and the timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario

I was told their ‘new russian import’ handles that and he does not know
how to read newsgroups =8-]
Pete, have you taught him yet? This is getting really ridiculous. Is
this rocket science or what?

  • igor

Mario Charest wrote:

I think Igor saw this problem a few months ago, if he couldn’t
get it to be fixed I guess there is little point in us reporting it > :wink:

I was hoping it was unrelated to Igor’s previous report.

“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9c57re$r7n$> 1@nntp.qnx.com> …
I too am having this problem, but because I am west coast the time
difference is much larger.
I noticed that if I log in using Phindows, click on the “Localization”
shelf
application, click on
each of the already highlighted items on the “Time Zone”, “Language” and
“Keyboard” tabs
(i.e. I make no changes) and then click “Apply”, the time corrects itself.

Go Figure!

raeberhardt@tantalus-systems.com
Randy Aeberhardt
Tantalus Systems.


“Mario Charest” <> mcharest@nozinformatic.com> > wrote in message
news:> 3ae074a7.17732988@inn.qnx.com> …




I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local machine,
everything is fine. The time is display as expected and the timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario

It appears that phrelay sets TZ if it is not already set, and it
sets it to “utc0”.

Mario Charest <mcharest@nozinformatic.com> wrote:


I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local machine,
everything is fine. The time is display as expected and the timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario


cburgess@qnx.com

Trouble is, if TZ is set, CS_TIMEZONE does not count. More trouble is,
CS_TIMEZONE is system-wide, while TZ is process-wide, so you can get
conflicting times in different programs if both are set.

Shame on you QSSL. Those are childish mistakes. Now tell us stories
about your 20 years expertize …
Of course everyone can do mistakes, but it soon will be a year since
they are known.

Colin Burgess wrote:

It appears that phrelay sets TZ if it is not already set, and it
sets it to “utc0”.

Mario Charest <> mcharest@nozinformatic.com> > wrote:



I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local machine,
everything is fine. The time is display as expected and the timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario


cburgess@qnx.com

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

Trouble is, if TZ is set, CS_TIMEZONE does not count. More trouble is,
CS_TIMEZONE is system-wide, while TZ is process-wide, so you can get
conflicting times in different programs if both are set.

Yes, I know. I’ve reported this to Garry.


cburgess@qnx.com

“Igor Kovalenko” <Igor.Kovalenko@motorola.com> wrote in message
news:3AE85739.2F704901@motorola.com

Trouble is, if TZ is set, CS_TIMEZONE does not count. More trouble is,
CS_TIMEZONE is system-wide, while TZ is process-wide, so you can get
conflicting times in different programs if both are set.

Shame on you QSSL. Those are childish mistakes. Now tell us stories
about your 20 years expertize …

And it’s 20 years experience with REAL TIME :wink:

Of course everyone can do mistakes, but it soon will be a year since
they are known.

Colin Burgess wrote:

It appears that phrelay sets TZ if it is not already set, and it
sets it to “utc0”.

Mario Charest <> mcharest@nozinformatic.com> > wrote:



I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local machine,
everything is fine. The time is display as expected and the timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario


cburgess@qnx.com

Okay guys,

does anyone know of a work-around. Everytime I forget to fix the time when
logging on
with Phindows, the timestamps get messed up on my source files and then
“make”
complains when I go to compile.

Randy.
paeberhardt@tantalus-systems.com



“Mario Charest” <mcharest@deletezinformatic.com> wrote in message
news:9cbhlu$4a2$1@inn.qnx.com

“Igor Kovalenko” <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3AE85739.2F704901@motorola.com> …
Trouble is, if TZ is set, CS_TIMEZONE does not count. More trouble is,
CS_TIMEZONE is system-wide, while TZ is process-wide, so you can get
conflicting times in different programs if both are set.

Shame on you QSSL. Those are childish mistakes. Now tell us stories
about your 20 years expertize …

And it’s 20 years experience with REAL TIME > :wink:

Of course everyone can do mistakes, but it soon will be a year since
they are known.

Colin Burgess wrote:

It appears that phrelay sets TZ if it is not already set, and it
sets it to “utc0”.

Mario Charest <> mcharest@nozinformatic.com> > wrote:



I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local machine,
everything is fine. The time is display as expected and the
timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario


cburgess@qnx.com

You can update the time of all of your files with

touch *

To recursively do that:

touch find . -name "*" -print

Be careful that you are in the correct directory though.

Markus


“Randy Aeberhardt” <raeberhardt@tantalus-systems.com> wrote in message
news:9ccq90$il0$1@nntp.qnx.com

Okay guys,

does anyone know of a work-around. Everytime I forget to fix the time
when
logging on
with Phindows, the timestamps get messed up on my source files and then
“make”
complains when I go to compile.

Randy.
paeberhardt@tantalus-systems.com



“Mario Charest” <> mcharest@deletezinformatic.com> > wrote in message
news:9cbhlu$4a2$> 1@inn.qnx.com> …

“Igor Kovalenko” <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3AE85739.2F704901@motorola.com> …
Trouble is, if TZ is set, CS_TIMEZONE does not count. More trouble is,
CS_TIMEZONE is system-wide, while TZ is process-wide, so you can get
conflicting times in different programs if both are set.

Shame on you QSSL. Those are childish mistakes. Now tell us stories
about your 20 years expertize …

And it’s 20 years experience with REAL TIME > :wink:

Of course everyone can do mistakes, but it soon will be a year since
they are known.

Colin Burgess wrote:

It appears that phrelay sets TZ if it is not already set, and it
sets it to “utc0”.

Mario Charest <> mcharest@nozinformatic.com> > wrote:



I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local
machine,
everything is fine. The time is display as expected and the
timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario


cburgess@qnx.com
\

Sorry, I guess I wasn’t clear enough. I was hoping that there was a
workaround to the time problem itself. Not correcting for its effects. Is
there a way to trick the system into setting the correct time by adding a
command into the .profile (or some similar file?).

Randy Aeberhardt
raeberhardt@tantalus-systems.com

“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:9ccr3j$rp9$1@inn.qnx.com

You can update the time of all of your files with

touch *

To recursively do that:

touch find . -name "*" -print

Be careful that you are in the correct directory though.

Markus


“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9ccq90$il0$> 1@nntp.qnx.com> …
Okay guys,

does anyone know of a work-around. Everytime I forget to fix the time
when
logging on
with Phindows, the timestamps get messed up on my source files and then
“make”
complains when I go to compile.

Randy.
paeberhardt@tantalus-systems.com



“Mario Charest” <> mcharest@deletezinformatic.com> > wrote in message
news:9cbhlu$4a2$> 1@inn.qnx.com> …

“Igor Kovalenko” <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3AE85739.2F704901@motorola.com> …
Trouble is, if TZ is set, CS_TIMEZONE does not count. More trouble
is,
CS_TIMEZONE is system-wide, while TZ is process-wide, so you can get
conflicting times in different programs if both are set.

Shame on you QSSL. Those are childish mistakes. Now tell us stories
about your 20 years expertize …

And it’s 20 years experience with REAL TIME > :wink:

Of course everyone can do mistakes, but it soon will be a year since
they are known.

Colin Burgess wrote:

It appears that phrelay sets TZ if it is not already set, and it
sets it to “utc0”.

Mario Charest <> mcharest@nozinformatic.com> > wrote:



I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local
machine,
everything is fine. The time is display as expected and the
timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario


cburgess@qnx.com


\

reset TZ to proper value. The proper value should be in /etc/TIMEZONE.

  • igor

Randy Aeberhardt wrote:

Sorry, I guess I wasn’t clear enough. I was hoping that there was a
workaround to the time problem itself. Not correcting for its effects. Is
there a way to trick the system into setting the correct time by adding a
command into the .profile (or some similar file?).

Randy Aeberhardt
raeberhardt@tantalus-systems.com

“Markus Loffler” <> loffler@ces.clemson.edu> > wrote in message
news:9ccr3j$rp9$> 1@inn.qnx.com> …
You can update the time of all of your files with

touch *

To recursively do that:

touch find . -name "*" -print

Be careful that you are in the correct directory though.

Markus


“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9ccq90$il0$> 1@nntp.qnx.com> …
Okay guys,

does anyone know of a work-around. Everytime I forget to fix the time
when
logging on
with Phindows, the timestamps get messed up on my source files and then
“make”
complains when I go to compile.

Randy.
paeberhardt@tantalus-systems.com



“Mario Charest” <> mcharest@deletezinformatic.com> > wrote in message
news:9cbhlu$4a2$> 1@inn.qnx.com> …

“Igor Kovalenko” <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3AE85739.2F704901@motorola.com> …
Trouble is, if TZ is set, CS_TIMEZONE does not count. More trouble
is,
CS_TIMEZONE is system-wide, while TZ is process-wide, so you can get
conflicting times in different programs if both are set.

Shame on you QSSL. Those are childish mistakes. Now tell us stories
about your 20 years expertize …

And it’s 20 years experience with REAL TIME > :wink:

Of course everyone can do mistakes, but it soon will be a year since
they are known.

Colin Burgess wrote:

It appears that phrelay sets TZ if it is not already set, and it
sets it to “utc0”.

Mario Charest <> mcharest@nozinformatic.com> > wrote:



I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local
machine,
everything is fine. The time is display as expected and the
timezone
is EST05 everywhere. Actually via telnet the TZ variable isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario


cburgess@qnx.com


\

“Randy Aeberhardt” <raeberhardt@tantalus-systems.com> wrote in message
news:9ck68q$45d$1@nntp.qnx.com

Sorry, I guess I wasn’t clear enough. I was hoping that there was a
workaround to the time problem itself. Not correcting for its effects. Is
there a way to trick the system into setting the correct time by adding a
command into the .profile (or some similar file?).

export TZ=getconf CS_TIMEZONE

Randy Aeberhardt
raeberhardt@tantalus-systems.com

“Markus Loffler” <> loffler@ces.clemson.edu> > wrote in message
news:9ccr3j$rp9$> 1@inn.qnx.com> …
You can update the time of all of your files with

touch *

To recursively do that:

touch find . -name "*" -print

Be careful that you are in the correct directory though.

Markus


“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9ccq90$il0$> 1@nntp.qnx.com> …
Okay guys,

does anyone know of a work-around. Everytime I forget to fix the time
when
logging on
with Phindows, the timestamps get messed up on my source files and
then
“make”
complains when I go to compile.

Randy.
paeberhardt@tantalus-systems.com



“Mario Charest” <> mcharest@deletezinformatic.com> > wrote in message
news:9cbhlu$4a2$> 1@inn.qnx.com> …

“Igor Kovalenko” <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3AE85739.2F704901@motorola.com> …
Trouble is, if TZ is set, CS_TIMEZONE does not count. More trouble
is,
CS_TIMEZONE is system-wide, while TZ is process-wide, so you can
get
conflicting times in different programs if both are set.

Shame on you QSSL. Those are childish mistakes. Now tell us
stories
about your 20 years expertize …

And it’s 20 years experience with REAL TIME > :wink:

Of course everyone can do mistakes, but it soon will be a year
since
they are known.

Colin Burgess wrote:

It appears that phrelay sets TZ if it is not already set, and it
sets it to “utc0”.

Mario Charest <> mcharest@nozinformatic.com> > wrote:



I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local
machine,
everything is fine. The time is display as expected and the
timezone
is EST05 everywhere. Actually via telnet the TZ variable
isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario


cburgess@qnx.com




\

“Mario Charest” <mcharest@deletezinformatic.com> wrote in message
news:9cbhlu$4a2$1@inn.qnx.com

“Igor Kovalenko” <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3AE85739.2F704901@motorola.com> …
Trouble is, if TZ is set, CS_TIMEZONE does not count. More trouble is,
CS_TIMEZONE is system-wide, while TZ is process-wide, so you can get
conflicting times in different programs if both are set.

Shame on you QSSL. Those are childish mistakes. Now tell us stories
about your 20 years expertize …

And it’s 20 years experience with REAL TIME > :wink:

Ah ha!

Real-time is NOT Time Zone Time!

Looks like they’re off the hook.

me wrote:

“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9ck68q$45d$> 1@nntp.qnx.com> …
Sorry, I guess I wasn’t clear enough. I was hoping that there was a
workaround to the time problem itself. Not correcting for its effects. Is
there a way to trick the system into setting the correct time by adding a
command into the .profile (or some similar file?).

export TZ=getconf CS_TIMEZONE

And where do we tell it that our RTC is set for UTC instead of local time?
I hate having to reset it twice a year (as if it was that accurate!) I know, if
I used W98
more often, it would reset it for me! What a workaround!

Randy Aeberhardt
raeberhardt@tantalus-systems.com

“Markus Loffler” <> loffler@ces.clemson.edu> > wrote in message
news:9ccr3j$rp9$> 1@inn.qnx.com> …
You can update the time of all of your files with

touch *

To recursively do that:

touch find . -name "*" -print

Be careful that you are in the correct directory though.

Markus


“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9ccq90$il0$> 1@nntp.qnx.com> …
Okay guys,

does anyone know of a work-around. Everytime I forget to fix the time
when
logging on
with Phindows, the timestamps get messed up on my source files and
then
“make”
complains when I go to compile.

Randy.
paeberhardt@tantalus-systems.com



“Mario Charest” <> mcharest@deletezinformatic.com> > wrote in message
news:9cbhlu$4a2$> 1@inn.qnx.com> …

“Igor Kovalenko” <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3AE85739.2F704901@motorola.com> …
Trouble is, if TZ is set, CS_TIMEZONE does not count. More trouble
is,
CS_TIMEZONE is system-wide, while TZ is process-wide, so you can
get
conflicting times in different programs if both are set.

Shame on you QSSL. Those are childish mistakes. Now tell us
stories
about your 20 years expertize …

And it’s 20 years experience with REAL TIME > :wink:

Of course everyone can do mistakes, but it soon will be a year
since
they are known.

Colin Burgess wrote:

It appears that phrelay sets TZ if it is not already set, and it
sets it to “utc0”.

Mario Charest <> mcharest@nozinformatic.com> > wrote:



I’m confused TZ says its UTC and CS_TIMEZONE says EST ???

  • Mario


    More info;

I’m working via Phindows, my time is 2 hours ahead.
In a terminal set reports TZ as being equal to UTC, but
CS_TIMEZONE shows EST05. The date command show
the same time as the shelf and indicates time zone to be UTC.

However if I login via telnet or start photon on the local
machine,
everything is fine. The time is display as expected and the
timezone
is EST05 everywhere. Actually via telnet the TZ variable
isn’t
even set.

I’v been trying to figure out where TZ is set, but I couldn’t
see how it could get set to UTC.

  • Mario


cburgess@qnx.com




\

Phil Olynyk wrote:

me wrote:

“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9ck68q$45d$> 1@nntp.qnx.com> …
Sorry, I guess I wasn’t clear enough. I was hoping that there was a
workaround to the time problem itself. Not correcting for its effects. Is
there a way to trick the system into setting the correct time by adding a
command into the .profile (or some similar file?).

export TZ=getconf CS_TIMEZONE

And where do we tell it that our RTC is set for UTC instead of local time?

rtc -s hw

I hate having to reset it twice a year (as if it was that accurate!) I know, if
I used W98
more often, it would reset it for me! What a workaround!

LOL

  • igor

Igor Kovalenko wrote:

Phil Olynyk wrote:

me wrote:

“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9ck68q$45d$> 1@nntp.qnx.com> …
Sorry, I guess I wasn’t clear enough. I was hoping that there was a
workaround to the time problem itself. Not correcting for its effects. Is
there a way to trick the system into setting the correct time by adding a
command into the .profile (or some similar file?).

export TZ=getconf CS_TIMEZONE

And where do we tell it that our RTC is set for UTC instead of local time?

rtc -s hw

Igor, do you mean : rtc -l hw ??? And I guess put it in rc.local to reset the
system’s idea of time. I confess that never occurred to me! As long as no files get
modified before then, the change should have no ill effects.
Thanks - Phil O

I hate having to reset it twice a year (as if it was that accurate!) I know, if
I used W98
more often, it would reset it for me! What a workaround!

LOL

  • igor

Phil Olynyk wrote:

Igor Kovalenko wrote:

Phil Olynyk wrote:

me wrote:

“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9ck68q$45d$> 1@nntp.qnx.com> …
Sorry, I guess I wasn’t clear enough. I was hoping that there was a
workaround to the time problem itself. Not correcting for its effects. Is
there a way to trick the system into setting the correct time by adding a
command into the .profile (or some similar file?).

export TZ=getconf CS_TIMEZONE

And where do we tell it that our RTC is set for UTC instead of local time?

rtc -s hw

Igor, do you mean : rtc -l hw ??? And I guess put it in rc.local to reset the

I mean -s. That means ‘update time in NVRAM’. The rtc -l actually reads
time from NVRAM and it also assumes local time there. So if your system
has date & local time set properly and you want to put UTC time into
NVRAM based on that, you do ‘rtc -s hw’.

  • igor

Igor Kovalenko a écrit :

Phil Olynyk wrote:

Igor Kovalenko wrote:

Phil Olynyk wrote:

me wrote:

“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9ck68q$45d$> 1@nntp.qnx.com> …
Sorry, I guess I wasn’t clear enough. I was hoping that there was a
workaround to the time problem itself. Not correcting for its effects. Is
there a way to trick the system into setting the correct time by adding a
command into the .profile (or some similar file?).

export TZ=getconf CS_TIMEZONE

And where do we tell it that our RTC is set for UTC instead of local time?

rtc -s hw

Igor, do you mean : rtc -l hw ??? And I guess put it in rc.local to reset the

I mean -s. That means ‘update time in NVRAM’. The rtc -l actually reads
time from NVRAM and it also assumes local time there. So if your system
has date & local time set properly and you want to put UTC time into
NVRAM based on that, you do ‘rtc -s hw’.

  • igor

As we are on the subject, do you know to get the date through TCP/IP (from a NT server)
?

Thanks,
Alain.