Subj : Perl::JAM (was: txt2pkt.pl)
To   : mark lewis
From : Maurice Kinal
Date : Wed Feb 23 2005 12:03 pm

Hey mark!

Feb 23 12:36 05, mark lewis wrote to Maurice Kinal:

 ml> my whole point is that the machine and the OS don't have a clue... 
 ml> all the machine can do is to keep the time in the BIOS clock and feed 
 ml> it to the OS when asked...

Okay.

 ml> the OS has to be _told_ what that time 
 ml> represents as far as UTC or localtime and if localtime, it must also 
 ml> be told what timezone...

If you don't tell it anything then it usually defaults to UTC and assumes the 
hardware clock is UTC as well.  I've also run across installations where you 
set the localtime to a zone and it assumes the hardware clock to be UTC and 
adjusts the localtime accordingly, which is usually wrong since most people set 
the time in the bios to localtime, which the bios usually knows nothing about 
and can't adjust for daylight savings time (some do, some don't).  Also I've 
seen installations that actually ask if the hardware clock is set to localtime 
and then ask what zoneinfo to use.  Thus it is possible to have two differing 
times for the hardware clock and localtime and that can work.  It often depends 
on the distribution and/or release as well as the relationship with the 
hardware clock upon installation.  I've seen differences over the years.

Anyhow the Perl POSIX module uses the system time rather then the hardware 
clock and does the adjustment for UTC according to that.  Same with "date".  If 
the zoneinfo is UTC then calls to either localtime or gmtime produce the exact 
same results and when anything other then UTC a call to gmtime will make the 
required adjustments.  So no matter what, UTC should always be the same unless 
the time has drifted (likely).  On one machine here I have to adjust the system 
time every so often since the system time drifts greater then the hardware 
clock especially when loads are heavy.  Things go out of sync rather 
dramatically.  In issues of timing that could be a problem and thus the "need" 
for a network time.  Having that UTC and making adjustments from there, if 
needed, is what I found to be best.  Furthermore in an international network 
UTC just makes sense since it is entirely possible to recieve messages before 
they were even written if the time shown doesn't provide any zoneinfo and no 
adjustments are made, either by the machine, system or man.

That is my story and I am sticking to it.  :-)

Life is good,
Maurice

--- Msged/LNX 6.1.2
 * Origin: Coffin Point - Ladysmith, BC Canada (1:153/401.1)

.