🚀 go-pugleaf

Ron House wrote:
> 
> I am starting to suspect you are right, that there is a newly created
> bug in here somewhere. But why am I the only person on the planet to
> notice it???

Probably because you are one of the few people to whom the
synchronisation of timestamps on linux and the DOS partition is
important.  I tried it on my 2.0.34 RedHat 5.1 system and saw the same
problem.

> My only lead at present is from Doug Moir, who suggests getting a new
> version of clock. I'll do that next.

I don't think that clock is the problem.  I think the error is in the
handling of VFAT timestamps.

> The explanation that makes most sense to me is that the kernel's
> variable sys_tz is set wrongly, but I don't know how to check its value
> or change it if it is wrong.
> 
> The commands date and date -u both show the right info.

As they do on my system, and this shows that the system is fully aware
of where it is, and what the UTC is.  If you try
date
date -u
  (as you have) and
/sbin/hwclock --show
/sbin/hwclock --utc --show
(which will show a time 10 hours *ahead* of local time if your hardware
is set to local time), and
perl -e '$gt = gmtime;print "$gt\n";$lt = localtime;print "$lt\n";'
and they all show consistent values, then both the hardware clock and
the system clock are working.

To Dietrich Timm:

Dietrich, the daylight saving flag would be a possible source of
difficulties, but would not explain a 10 hour difference, and is not
relevant to Queensland because, sensibly, we do not have daylight
saving.  I believe that nowadays win95 recognises this difference
between Queensland and the southern states.

Yours faithfully,
-- 
 __ /__   Peter B. West  p.west@uq.net.au
   /     http://www.uq.net.au/~zzpwest
  /     "Lord, to whom shall we go?"