[time-nuts] Concern over Daylight Saving Time

Didier Juges didier at cox.net
Sat Jan 20 10:52:17 EST 2007


Does it mean I should consider upgrading these 2.2.6 linux kernel boxes?
:-)

Joke apart, I would think that in any case, January should not be 
affected by the upcoming change in daylight saving time.

I just wanted to know if anyone had noticed a similar problem.

I have seen the postings about Red Hat, and this is not my problem. 1) I 
use Slackware (yes, no comments please) and 2) system time is wrong 
using the "date" utility in the default mode (runs through timezone). If 
I query system time in UTC (date -u I believe, or something like that), 
it is correct.  In any event, the only applications that run on these 
machines, other than apache and all the goodies that came with Slackware 
(mostly system utilities, these boxes don't even have X, they don't even 
have a monitor attached to them, just ethernet) are programs I wrote (C 
and Perl), and they simply get system time using standard function calls.

I believe the Red Hat patch was simply to link the timezone info to the 
various places that different programs are looking for. In my minimum 
Slackware installation, I have found at least 5 links to timezone (in 
etc, var, lib, usr and a couple of different subdirs). Fortunately, 
there seems to be only one file, all the rest are symlinks.

Maybe the timezone file was bad from the beginning. I'll try MST :-)

Thanks

Didier


John Ackermann N8UR wrote:
> As far as I am aware, all of the main Linux distributions had updates
> available to bring the timezone tables up to date.  But if systems
> aren't being updated on a regular basis, they won't get the new
> information.  It's possible that those Red Hat machines hadn't had
> updates run in some time.
>
> Linux systems need regular updates just the same as MS ones do.
>
> John
> ----
>
> Mike Suhar said the following on 01/20/2007 09:30 AM:
>   
>> 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
>>
>>
>> _______________________________________________
>> time-nuts mailing list
>> time-nuts at febo.com
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>
>>
>>     
>
>
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
>   



More information about the time-nuts mailing list