[102489] in RedHat Linux List
Re: Setting kernel timezone and dst?
daemon@ATHENA.MIT.EDU (Tony Nugent)
Thu Dec 3 12:46:13 1998
To: Redhat Email List <redhat-list@redhat.com>,
RedHat Development Mailing List <redhat-devel-list@redhat.com>
Cc: Eric Knudstrup <eknuds@extremenetworks.com>
Reply-To: RedHat Development Mailing List <redhat-devel-list@redhat.com>
In-Reply-To: message-id <8F76211F5DB3D1119F6F00A0C95A6630A15656@SOL>
of Wed, Dec 02 13:24:27 1998
Date: Fri, 04 Dec 1998 02:39:41 +1000
From: Tony Nugent <Tony.Nugent@usq.edu.au>
Resent-From: redhat-list@redhat.com
[ Originally posted to redhat-digest (should this really be a valid
address to post email to?), replied to redhat-list and
redhat-devel-list. And if I could find the email address of the
person(s) who wrote /sbin/hwclock and/or maintains the util-linux
package, I'd Cc a copy in that direction too. (Can someone forward
this on? thanx) ]
On Wed Dec 02 1998 at 13:24, Eric Knudstrup wrote:
> From using smbfs I noticed that the timezone is not getting set in the
> kernel (however, it is correctly shown in user space.)
> I was wondering how I can resolve <symbolic timezone name> -> +- minutes
> west or so I can set this (The last version I checked was 5.1 and it still
> isn't set up right).
> Right now I have a sysinit hack but I would like something a little nicer.
>
> Pointers to docs welcome.
This is a bug and a REAL problem, and it needs to be fixed. More
specifically, the bug (or omission) appears to be in /sbin/hwclock from the
util-linux package. If this program told the kernel what the time zone
difference was, then what Eric observes would simply not occur.
It not only happens for smbfs, but also for msdos/vfat mounted
partitions and samba shares on linux boxes.
Try it: touch a file in a dos partition with linux, then go to dos/win and
see what the timestamp is. Then create a file and go back to linux to see
what this timestamp is. They will be ahead or behind by a factor equal to
the timezone difference. It's even easier to see for samba shares - you
don't have to reboot to that other so-called operating system:)
I'm the "linux support person" around here. When this particular problem
was bought to my attention a couple of months ago, at first found it hard
to believe. But I was soon convinced otherwise. It was a source of great
woe to some people here who depended on correct timestamps across dos/linux
filesystems for some of the things they needed to do. I sent mail to a
couple of mailing lists about this issue, with no worthwhile response (heh,
none at all).
Below here is some correspondence Cc'ed in my direction when the problem
was isolated, and a hacked solution devised. It includes a little C
program that can be run to update the kernel's knowledge of what the
timezone difference really is.
This functionality needs to be put into /sbin/hwclock to fix this problem
once and for all. (And if this isn't the right place, then fixed wherever
it needs to be done... perhaps it is a libc issue).
Cheers
Tony
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
Tony Nugent <Tony.Nugent@usq.edu.au> <linux@usq.edu.au>
Computer Systems Officer Faculty of Science
University of Southern Queensland, Toowoomba Oueensland Australia
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
=======8<------ a good old fashioned cut --------------------
Date: Thu, 01 Oct 1998 16:29:34 +1000
From: Ron House <house@usq.edu.au>
Subject: Re: A whacky DATE bug in Linux - SOLVED!
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.
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com http://archive.redhat.com
To unsubscribe: mail redhat-list-request@redhat.com with
"unsubscribe" as the Subject.
