Re: Data, Time, and all that.

[Tass Mailing List <tass@mail.alembic.net>]

On Sun, 11 Mar 2007, Thomas F. Droege wrote:

> Date: Sun, 11 Mar 2007 09:05:16 -0500
> From: Thomas F. Droege <droege@fastmail.fm>
> To: tass@tass-survey.org
> Subject: Data, Time, and all that.
>
> I ran last night.  Now the question is, how is it time stamped?  My
> fancy watch sprung forward as it should have and now reads the correct
> local time.  My data taking computers which are running on NTP did not.
> My fancy alarm clock which is supposed to set itself from Bolder did not
> spring forward.  I thought it and the wrist watch worked from the same
> source, sigh!
>
> Since the computer time did not change on the data taking computers (I
> just checked one since the others are up in the dome) I assume that the
> times in the data should be OK.  What do you all think?  Rob?  Michael?
> Should we segregate the next two weeks of data until it can somehow be
> checked?
>
> Time is fun.  It is not so easy.
>
> Tom Droege

don't know about the alarm clock.

ntp doesn't know about time zones, it just keeps your clock set to UTC,
and does a super good job of that.

in linux there is a timezone directory that in most distributions has a
symbolic link from /etc/localtime to the timeinfo directory/region/zone
and this file has the offset from UTC as well as dates info that triggers
the daylight saving time changes.

the easiest way for right now is to use the alternate and link /etc/
localtime to /usr/share/zoneinfo/Etc/GMT-n where n is the proper offset
for Batavia.  this will fix each machine's localtime to read properly for
now but won't know anything about DST changes.   then you have all summer
to get a new zoneinfo structure set up with the new dates for fall.

in a happier world perhaps the leaf nodes in zoneinfo would be in ascii
and you could just edit the dates yourself.  unfortunately their in some
binary format so not easy for the end-user to edit.

-ron