🚀 go-pugleaf

Peter B. West wrote:
> Ron House wrote:
> >
> > Is it really true that DOS filesystems have the correct dates everywhere
> > in the world but in Australia? If so, the timezone files must be wrong.
> > But I don't know how to fix them.
> 
> It might be something like this:
> 
> If the hardware clock is set to the local time zone (which I think it
> has to be for Win95, at least), and /etc/sysconfig/clock is correctly
> set up, then /etc/rc.d/rc.sysinit will call /sbin/hwclock with the arg
> `--hctosys', but without the arg `--utc'.  The local time will be
> converted to UTC (GMT) and that time will be used for the system clock,
> which will be maintained by interrupts to the OS, independently of the
> hw clock.  All file timestamps will be made in UTC, and converted as
> required to local time for display.
> 
Thanks Peter. I am really starting to suspect a bug in Linux somewhere,
perhaps even in the kernel. I have now checked out all the things people
have suggested and none of them work.

Ken Yap suggested
> If you are using DOS you have to use local time in the hardware clock
> instead of GMT. Then you tell Linux to cope with that by specifing
> localtime in /etc/sysconfig/clock: UTC=false ARC=false.

This is true, but unfortunately doesn't fix the problem (my system was
already set up that way). I have also been told to try:

/sbin/clock -s

but it doesn't work. Don Collins suggested:

ln -s /usr/share/zoneinfo /usr/lib/zoneinfo

which certainly makes sense, but unfortunately didn't work. I was also
told to try

/sbin/hwclock --hctosys

which also makes sense, but didn't work.

> When reading a timestamp on a linux filesystem, the software must
> translate timestamp from UTC to local time; when reading a win95
> timestamp, it must first translate from local to UTC, then feed that
> time into the normal timestamp algorithm.  If this is not happening, the
> bug is in the vfat file system handler.  Maybe it happened with the
> introduction of FAT32 support, or maybe there are differences in the way
> win95, win98 and NT handle file timestamps, and that this is causing
> problems.

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???

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

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.

-- 
Ron House            house@usq.edu.au

You can only be right if you have the courage to be wrong.