[time-nuts] Concern over Daylight Saving Time

[Mike Suhar]

Hi Didier,

I don't know if this has any relationship to your issue or not but I will
toss it on the table.  Back in the fall when we switch from Daylight to
standard time we started to get complaints from our Linux users (Sun Solaris
systems were fine) that our Microsoft terminal servers were off by one hour
(still showing DST).  We know that nothing would ever be wrong with a Linux
machine so we looked over those terminal servers for any possible problem
with time or time zone.  Microsoft surely messed something up.  We could
find nothing.  Since the problem was only with Linux systems we pushed the
problem back to that group.  Well they found something.  They had to apply a
patch so applications would get the correct time zone information.  I think
the time was fine on the console, just some applications such as terminal
server would get it wrong.  Unfortunately I can not remember the details of
the issue.  This was on Red Hat Linux.  If this sounds like it could be the
problem I can ask one of our Linux admins for details.  

Mike



-----Original Message-----
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of Didier Juges
Sent: Saturday, January 20, 2007 9:11 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Concern over Daylight Saving Time

Hal Murray wrote:
>> 	Actually, if you're using a network time server on your home LAN,
and
>> sync'ing your workstations to it, you need only make sure that the
>> time server is running right. The computers will then take care of
>> themselves. 
>>     
>
> NTP uses UTC.  (Roughly.  There might be differences at the leap second 
> level.)
>
> Time zones and DST depend upon local conversions.  You have to get that
right 
> if you expect local time to be correct.
>
> Most *inx boxes use a local conversion table/file stored in /etc/locatime
>
>
>   
That brings another question. I have a few linux boxes at work 
performing thankless http server duties and I have never been 
excessively worried about time or even date on those machines until 
someone pointed out to me a couple of weeks ago that a script used to 
retrieve documents in a database was setting the date of the query to 
February 2037. I checked and lo, that was the system date of the 
machine! After a little bit of searching, I found out the time server I 
was using (rolex.usg.edu I think, for about 4 years I guess) was either 
returning garbage or was returning something suddenly my netdate utility 
would not understand. I have been updating time each day in the AM (cron 
job) from the same machine (and others, I need to check) for years. I 
switched to another time server and all is good for now, with one 
exception. I have the timezone set to CST (Chicago), since that's where 
I am, but it sets the offset to only 6 hours instead of 7. To be honest, 
I do not know if this has always been the case (when rolex was working) 
or if this is new, as I say, I am not too worried about time/date on 
this machine, but 2037 was a bit much.... The same happens if I set the 
system clock from the CMOS instead of the time server. The CMOS is also 
set to UTC and correct. It is as if my timezone is wrong, but I reloaded 
from a *believed good* original and no dice.

What am I doing wrong?

Didier KO4BB

_______________________________________________
time-nuts mailing list
time-nuts at febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts