[plug] CVS timezones

[Michael Hunt]

On Tue, 2003-04-29 at 14:18, Ryan wrote:

> On Tue, 2003-04-29 at 13:56, Kai wrote:

> > I could be wrong but I think you need to add +0800 like this:
> > Tue Apr 29 13:35:24 +0800 WST 2003
> 
> How do I add that?  +0800 doesn't appear to be a valid 'thing' to pass to 
> 'date --set="things"' and I normally use ntpdate to set the clock which
> doesn't seem to be well educated on GMT offsets.
> 
> Is the +0800 set by the timezone config or by whatever sets the time 
> (date/ntpdate etc)?
> 
> I would have thought WST would do the job, but I have seen systems that
> report +xxxx as you suggested.
> 
> When I install Debian I always say the clock is set to GMT 
> (even if it isn't) as I never bothered to find out what that question was 
> really asking.  Am I wrong to do that?  If so, how do I fix it?
> 
> *blank stare*
> 
> Ryan 

Any of the tz utils (tzconfig, tzselect, tzsetup) on debian will allow
you to configure the time zone of the machine. Certain operating systems
and there associated utils allow this to be done as a human readable
zone (i.e. WST) or as a UTC offset (i.e. +0800). The two are
interchangeable however, some time zones have daylight savings,
winter/summer time etc that the offset does not easily take into
account, hence the human readable timezone format (don't know what it is
officially called) is the better one to use.

The question the debian install was asking you was weather you wanted
the hardware clock set to local time or UTC. Having it set to UTC means
that you can easily change the timezone without having to change the
hardware clock (which in the IBM PC/Intel world has some interesting
problems associated with it due to historical short sighted design).
Certain operating systems require that the hardware clock be set to the
local timezone and if you setup your Linux box to dual boot, the time on
your other OS would be wrong if you set the hardware clock to UTC time
and you were not in a UTC timezone.

I would venture a guess and say that system timezone config does not
appear to be your problem. The date command you pasted to an earlier
post shows that it is at least picking up the right timezone and
presenting the correct date and time based on this. My thoughts would be
that there is some reasoning (maybe config or program logic) that CVS is
using as its basis for displaying the time as GMT. Possibly with
programmers logging patches from all around the world CVS's logic may be
that by using GMT only it has found the most prudent way of keeping
track of patches posted from all sorts of different timezones.

I'm not a CVS user or admin and know absolutely nothing about the inner
going ons of CVS so I can be, and are likely to be, totally wrong :-)

Hope the other stuff clears up any timezone misgivings you had though.

Michael Hunt