🚀 go-pugleaf

Peter B. West wrote:
> 
> Ron House wrote:
> >
> > I devised a program based on Harald's to apply a -10 hour correction (as
> > Australia is east of Grenwich). Anyone with this problem west of there
> > should apply a positive correction. Unfortunately I seem to have failed
> > to copy the directory with the program, so I'll post it tomorrow.
> 
> I must be missing something.  How can /sbin/hwclock --show,
> /sbin/hwclock --show --utc, date, date -u, and the perl gmtime and
> localtime calls all do the right thing if the kernel doesn't know what
> is going on?  (Note that /sbin/clock is a link to /sbin/hwclock.)

There is an internal kernel variable called sys_tz, which is completely
separate from the user space timezone system. date etc. all work off the
user space system and all work because the timezone is set up correctly.
However, that kernel variable (which is not used in any utilities (date,
ls, etc) was zero. The kernel needs it because stat must report GMT for
all file timestamps, and DOS files have a local timestamp, so the kernel
must subtract it to pass a GMT to the user program, which then adds the
(user space) timezone back on again. Apparently, DOS timestamps are
about the only thing the Kernel needs a timezone for, as everything
Unixy is done outside the kernel.

> I took Harald's advice and RTM.  Herewith from the man page
>   gettimeofday, settimeofday - get / set time
> 
> I am running RH5.1 2.0.34,  The man page is marked
> `Linux 2.0.32 10 December 1997'
> 
>        struct timezone {
>                int  tz_minuteswest; /* minutes W of Greenwich */
>                int  tz_dsttime;     /* type of dst correction */
>        };
> 
>        The use of the timezone struct is obsolete; the tz_dsttime
>        field has never been used under Linux - it  has  not  been
>        and  will  not  be  supported  by libc or glibc.  Each and
>        every occurrence of this field in the kernel source (other
>        than  the  declaration)  is  a bug. Thus, the following is
>        purely of historic interest.
> 
> Now fair enough, the *field* tz_dsttime is completely unused, and is not
> used in Harald's program.  But the man page claims that the `timezone
> struct' is obsolete, not just tz_dsttime.  Caveat emptor.

Well, this is one guy who'll take correct DOS file timestamps today and
caveat the emptor on another occasion. The following program solves the
problem. It hard codes a negative 10-hour shift, as Australia is 10
hours ahead of GMT; others will need to adjust appropriately:

#include <sys/time.h>
#include <unistd.h>
int main( int argc, char *argv[] )
{
        struct timezone tz;
        struct timeval tv;
        gettimeofday( &tv, &tz );
        if (tz.tz_minuteswest == 0) {
                settimeofday( NULL, &tz );
                tz.tz_minuteswest = -10 * 60; /* or whatever */
                tz.tz_dsttime = 0;
                settimeofday( NULL, &tz );
        }
        return 0;
}

The above is written so it will act as a no-op if there is already a
nonzero timezone; that way it won't cause trouble if it is put in the
boot script and forgotten and then the official program gets fixed. NB:
Both calls to settimeofday are necessary.

Thanks again to all who have taken the time to help and comment.

-- 
Ron House            house@usq.edu.au

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