Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DST2007, Timezone variable, and ntp

0 views
Skip to first unread message

Joe D.

unread,
Feb 22, 2007, 11:18:10 AM2/22/07
to
Hello all;

Ive perused the postings surrounding DST2007, and haven't seem my
particular issue addressed. I'm administering a bunch of older boxes,
none of which are patched to be ready for the shift in the DST (from
starting in April to now starting in March). Some I can patch, some
are too old and running versions of Solaris where there are no freely
available patches. Additionally, our timezone variable is set to US/
Eastern, instead of EST5EDT, which is what it should be, (if we're in
the Eastern time zone, and observe Daylight Saving Time, right?).

Our method of keeping time in sync is to rdate to a single server
(timehost) each nite via cron. This server gets it's time from an
internet-synching server. I plan on replacing this method with ntp,
but may not get it complete by March 11th. I have already patched our
'timehost' server to be ready for the new timzone files for DST 2007.
zdump confirms the date will change as planned.

I've already confirmed with our various SW vendors that their products
make no use of the $TZ variable, but simply get their time from the
system time. JAVA is being patched with the tzupdate utility where
applicable. My thinking is that if all the other servers have a $TZ
setting of US/Eastern, then the shift in time will not affect them,
and I need not apply the patches. The only server I would WANT the $TZ
to reflect EST5EDT, and therefore change the time forward and back
would be our 'timehost' server.

Can someone please let me know what risks/exposure/general badness I
am running, if any (other than being WAY behind in patching these
servers, which I'm addressing slowly via attrition), by simply keeping
our existing 'rdate via cron', and eventually via ntp method of time
sync-up?

Any input on areas I've overlooked is appreciated.

Thanks in advance, as always...

Joe D.

Darren Dunham

unread,
Feb 22, 2007, 11:52:46 AM2/22/07
to
Joe D. <newbie_fr...@yahoo.com> wrote:
> Ive perused the postings surrounding DST2007, and haven't seem my
> particular issue addressed. I'm administering a bunch of older boxes,
> none of which are patched to be ready for the shift in the DST (from
> starting in April to now starting in March). Some I can patch, some
> are too old and running versions of Solaris where there are no freely
> available patches. Additionally, our timezone variable is set to US/
> Eastern, instead of EST5EDT, which is what it should be, (if we're in
> the Eastern time zone, and observe Daylight Saving Time, right?).

Try just copying over a set of /usr/share/lib/zoneinfo files from a
working server.

> Can someone please let me know what risks/exposure/general badness I
> am running, if any (other than being WAY behind in patching these
> servers, which I'm addressing slowly via attrition), by simply keeping
> our existing 'rdate via cron', and eventually via ntp method of time
> sync-up?

Uh. It won't work.

NTP ticks UTC. The zoneinfo files map UTC to a local time. *that* is
what changes.

NTP does not know about timezones, does not communicate timezones. That
is handled by the local machine.

'date -u' will be correct on your machine with NTP working.
'TZ=US/Eastern date' will be off an hour unless you replace the zoneinfo
files.

--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

Joe D.

unread,
Feb 22, 2007, 3:06:20 PM2/22/07
to
Thanks for the reply, Darren; a couple of follow ups, if you have the
time?:

>
> Try just copying over a set of /usr/share/lib/zoneinfo files from a
> working server.
>

Will do.

>
> Uh. It won't work.
>

It won't work if I keep the current methof of simply using rdate, or
it won't work if I try and use ntp without first deploying correct
zoneinfo files?

> NTP ticks UTC. The zoneinfo files map UTC to a local time. *that* is
> what changes.
>
> NTP does not know about timezones, does not communicate timezones. That
> is handled by the local machine.
>
> 'date -u' will be correct on your machine with NTP working.
> 'TZ=US/Eastern date' will be off an hour unless you replace the zoneinfo
> files.
>

Right; on one machine, I simply copied the EST5EDT zoneinfo file to
the /US/Eastern timezone file, and the zdump utility told me that it
would switch the time as expected. This is kocher? Or should I simply
change my TZ to EST5EDT?


Darren Dunham

unread,
Feb 22, 2007, 4:24:35 PM2/22/07
to
Joe D. <newbie_fr...@yahoo.com> wrote:

>> Uh. It won't work.
>>
> It won't work if I keep the current methof of simply using rdate, or
> it won't work if I try and use ntp without first deploying correct
> zoneinfo files?

I don't know how rdate works. It probably just transmits a local date.
If so, your local clock would show a correct time, but the actual
timestamps would be off an hour. When you correct the clock (either
because you fix the zoneinfo files, or the local machine thinks DST has
begun), the timestamps will show an hour off. I don't regard that as a
good thing.

With NTP, your local clock will show an hour off if you use the old
timezone data.

> Right; on one machine, I simply copied the EST5EDT zoneinfo file to
> the /US/Eastern timezone file, and the zdump utility told me that it
> would switch the time as expected. This is kocher? Or should I simply
> change my TZ to EST5EDT?

I would move the zoneinfo directory whole, not just one file.

In addition, I would generally prefer US/Eastern or America/New_York to
EST5EDT.

hennessy

unread,
Feb 26, 2007, 2:06:27 PM2/26/07
to
In article <yTjDh.349$LF6...@newssvr11.news.prodigy.net>,

Darren Dunham <ddu...@redwood.taos.com> wrote:
>Try just copying over a set of /usr/share/lib/zoneinfo files from a
>working server.

This won't fix hardcoded stuff in libc... Not everything uses
zoneinfo :/
--
"When in doubt, use brute force."
- Ken Thompson

Casper H.S. Dik

unread,
Feb 26, 2007, 4:58:40 PM2/26/07
to
henn...@earl-grey.cloud9.net (hennessy) writes:

>In article <yTjDh.349$LF6...@newssvr11.news.prodigy.net>,
>Darren Dunham <ddu...@redwood.taos.com> wrote:
>>Try just copying over a set of /usr/share/lib/zoneinfo files from a
>>working server.

> This won't fix hardcoded stuff in libc... Not everything uses
>zoneinfo :/

What doesn't? The only thing not using zoneinfo is stuff using
XSTdXDT timezones; so unless you have software which manipulates
times in your non-system timezone, you are safe.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Thomas Schulz

unread,
Feb 27, 2007, 11:41:13 AM2/27/07
to
In article <nSnDh.384$LF6...@newssvr11.news.prodigy.net>,

Darren Dunham <ddu...@redwood.taos.com> wrote:
>Joe D. <newbie_fr...@yahoo.com> wrote:
>
>>> Uh. It won't work.
>>>
>> It won't work if I keep the current methof of simply using rdate, or
>> it won't work if I try and use ntp without first deploying correct
>> zoneinfo files?
>
>I don't know how rdate works. It probably just transmits a local date.
>If so, your local clock would show a correct time, but the actual
>timestamps would be off an hour. When you correct the clock (either
>because you fix the zoneinfo files, or the local machine thinks DST has
>begun), the timestamps will show an hour off. I don't regard that as a
>good thing.
>
>With NTP, your local clock will show an hour off if you use the old
>timezone data.
>
>> Right; on one machine, I simply copied the EST5EDT zoneinfo file to
>> the /US/Eastern timezone file, and the zdump utility told me that it
>> would switch the time as expected. This is kocher? Or should I simply
>> change my TZ to EST5EDT?

Do not use EST5EDT. That goes around the timezone files and uses hard coded
information in libc (which you can not patch on old systems). Copy the
US/* tree from a patched system to the older system and use US/Eastern.


>I would move the zoneinfo directory whole, not just one file.

Yes, that would be best. Just take the whole zoneinfo tree from a patched
system to the old system.


>In addition, I would generally prefer US/Eastern or America/New_York to
>EST5EDT.
>
>--
>Darren Dunham ddu...@taos.com
>Senior Technical Consultant TAOS http://www.taos.com/
>Got some Dr Pepper? San Francisco, CA bay area
> < This line left intentionally blank to confuse you. >


--
Tom Schulz
sch...@adi.com

0 new messages