🚀 go-pugleaf

>The problem:
>
>I am having trouble with my DOS partitions. I upgraded from Red Hat 4 to
>RedHat 5.1 and since then all the datestamps on files in DOS partitions
>are 10 hours ahead of their true time when checked from within Linux. As
>I am in Queensland Australia (10 hours ahead of GMT) this is obviously a
>time zone problem. But I have checked:
>
>Win95 says: Timezone Brisbane (GMT+10)
>Linux says: Australia/Queensland
>/etc/sysconfig/clock says UTC is false
I'm no expert and am curently running W98 (blush) so can't use man,
but I *think* the above lines say to linux that machine clock is not
running UTC (traditionally *nix machines have machine clock running
UTC). linux datestamps using UTC; thus it adds 10 hours to any
datestamp it finds, to match the Australia/Queensland offset. 

Anyway, suggest reading man pages etc on the topic.

DOS of course assumes the whole world runs on Micro$oft time. [and
note W95 includes timezone stuff without any (obvious) way of
correcting it, so of course got it wrong for southern east Oz daylight
saving - not that they have much hope given politicians change the
rools about twice a year] 

Ron House wrote:
> I am having trouble with my DOS partitions. I upgraded from Red Hat 4 to
> RedHat 5.1 and since then all the datestamps on files in DOS partitions
> are 10 hours ahead of their true time when checked from within Linux. As
> I am in Queensland Australia (10 hours ahead of GMT) this is obviously a
> time zone problem. But I have checked:
> 
> Win95 says: Timezone Brisbane (GMT+10)
> Linux says: Australia/Queensland
> /etc/sysconfig/clock says UTC is false
> Both systems agree on the current time.

I was getting some stuff like this when I switched from Slackware 3.0
(with the 2.0.0 kernel) to Slackware 3.3 (with the 2.0.30 kernel),
except that I am in Switzerland and the time difference was 2 hours
instead of 10.  The problem was with the RTC (Real Time Clock) module
that didn't work with my box (a 486DX4).

Look for an error message on booting up (or in /var/adm/syslog) that
looks something like:
modprobe: Can't locate module char-major-10-135

Errors messages involving /dev/rtc might be significant too.

If I remember correctly, the trick was to have Linux look at the CMOS
clock everytime it booted by including the following line in
/etc/rc.d/rc.S :

/sbin/clock -s

If you don't have error messages like this, it is probably another
problem.  All of this is from vague memory since my notes are a bit
sketchy.  I suggest you try to find the thread on Dejanews.

Good luck and let me know if this info was any help.

Erik Rossen
rossen@planet.ch

Ron House <house@usq.edu.au> writes:

> This is my second post about this problem. I only got a few replies to
> my first, and I am reasonably certain this is a bug in Linux.

I think there is a bug but not the bug you think.

If I set both kernel and user space timezones to Australia/Queensland
(at this time of year) the kernel thinks I'm in GMT+11 and the user
space thinks I'm in GMT+10.

The bug appears to be that there is confusion (disagreement?) about
the meaning of the tz_dsttime member of the struct timezone structure.

If I look at a dos filesystem the timestamps are *one* hour out *not*
ten hours out.  If you are seeing 10 hours out then I'd guess one of
your timezones is set wrong.

First check that your system clock is right.  Do "date -u".  Do you
see the correct UCT time?

-- 
     \\   ( )  No male bovine  | Email: B.A.McCauley@bham.ac.uk
  .  _\\__[oo   faeces from    | Phones: +44 121 471 3789 (home)
 .__/  \\ /\@  /~)  /~[   /\/[ |   +44 121 627 2173 (voice) 2175 (fax)
 .  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
  # ll  l\\  ~~~~ ~   ~ ~    ~ | http://www.wcl.bham.ac.uk/~bam/
 ###LL  LL\\ (Brian McCauley)  |

Brian McCauley wrote:

> If I set both kernel and user space timezones to Australia/Queensland
> (at this time of year) the kernel thinks I'm in GMT+11 and the user
> space thinks I'm in GMT+10.
> 
What command do you use to find out who thinks what?

> If I look at a dos filesystem the timestamps are *one* hour out *not*
> ten hours out.  If you are seeing 10 hours out then I'd guess one of
> your timezones is set wrong.
> 
No. I have checked this carefully. I have received a suggestion in email
that I think might be the answer, but I have to go home to check. I'll
post tomorrow if I find the solution.

-- 
Ron House            house@usq.edu.au

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

Ron House wrote:
> 
> This is my second post about this problem. I only got a few replies to
> my first, and I am reasonably certain this is a bug in Linux.
> 
> The problem:
> 
> I am having trouble with my DOS partitions. I upgraded from Red Hat 4 to
> RedHat 5.1 and since then all the datestamps on files in DOS partitions
> are 10 hours ahead of their true time when checked from within Linux. As
> I am in Queensland Australia (10 hours ahead of GMT) this is obviously a
> time zone problem. But I have checked:
> 
> Win95 says: Timezone Brisbane (GMT+10)
> Linux says: Australia/Queensland
> /etc/sysconfig/clock says UTC is false
> Both systems agree on the current time.
> 
> One person suggested this:
> 
> > I had the same problem too when i installed RH5.1. It seems there is no
> > such problem with people elsewhere
> > but in Australia.
> > What i did was to set back the time in the BIOS one day before and started
> > the installation.
> 
> I haven't tried this yet, but I have the deepest suspicion that this
> will not work. Someone else said:
> 
> > I'm fairly sure that both the "date" and the "clock" command will set
> > the kernel space timezone to match the user space one whenever they
> > set the kernel clock.
> >
> I tried it and it didn't work.
> 
> 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.

When windows creates a file, it will presumably timestamp it with the
local time, which, traditionally, is the only one that windows
understands.  There will therefore be a 10 hour difference between the
timestamps on files created at the same time by windows and linux (in
Queensland, anyway).

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.

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

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.

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

sys_tz can be set with settimeofday().

Try this C program:

====== BEGIN settz.c ======
#include <sys/time.h>
#include <unistd.h>

int main( int argc, char *argv[] )
{
        struct timezone tz;
        tz.tz_minuteswest = -10 * 60; /* or whatever */
        tz.tz_dsttime = 0;
        settimeofday( NULL, &tz );
}
====== END settz.c ======

And look at the man page for settimeofday!

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Harald Hoffmann                              Voice:   + 43 1 8958499 19
g.a.m.s. edv-dienstleistungen gmbh           Fax:     + 43 1 8958499 60
Stiegergasse 15-17/8                         E-mail:  ari@gams.at
A-1150  Wien/Austria/Europe                  nic-hdl: HH145-RIPE
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Ron House wrote in message <36087C67.3313582C@usq.edu.au>...
[snip]
>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???
>>

Maybe you need a new battery for your clock?  ^L^

>--
>Ron House            house@usq.edu.au
>
>You can only be right if you have the courage to be wrong.

Ron House wrote:

> I am having trouble with my DOS partitions. I upgraded from Red Hat 4 to
> RedHat 5.1 and since then all the datestamps on files in DOS partitions
> are 10 hours ahead of their true time when checked from within Linux. As
> I am in Queensland Australia (10 hours ahead of GMT) this is obviously a
> time zone problem. But I have checked:
>
> Ron House            house@usq.edu.au
>
> You can only be right if you have the courage to be wrong.

  Ron,
    I am using SuSE 5.3.  There is a similarity here, though, between RH and
SuSE concerning this time problem.  I live in Mannheim, Germany,  If I use the
MET (Middle Eastern Time), then the clock is always one hour off.  However, if
I use GMT+1, and make sure that Liunx recognizes this as my local time (it
prompts for GMT or local time during the setup), Linux displays the correct
time.
    Linux uses YAST for setting up the computer.  I do not have any experience
with RedHat.  I am pretty sure, though, that there must be something similar.
Instead of using Queensland, Australia, when setting up the system, try GMT+10
and local time.  I think that this will probably take care of your problem.

Greetings Downunder :)

David


PS Maybe the problem is that the computer is upside down!? :)

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

[cold.apps and non-existant groups removed]

David <starman@regio-info.de> writes:

[...]

>  Ron,
>    I am using SuSE 5.3.  There is a similarity here, though, between RH and
>SuSE concerning this time problem.  

Uh. I don't think so.

>I live in Mannheim, Germany,  If I use the
>MET (Middle Eastern Time), then the clock is always one hour off.  

[...]

Sure. MET is wrong. And, btw, it's Middle European Time.

MEST would be the correct time zone, but then, neither MET nor
MEST is RFC-compliant where it comes to newspostings. The correct
setting would be strictly numerical +0100 . Anyone having a valid
timezone definition for this one ?

Michael
-- 
Michael Buchenrieder * mibu@scrum.muc.de / mibu@scrum.greenie.muc.de
       Lumber Cartel Unit #456 (TINLC) and Official Net.Scum 

Thanks to all the kind people who volunteered their suggestions to help
me with this problem. I have now found the solution. It was Doug Moir
who put me onto the right answer with this suggeestion:

>There is a bug in the program clock(8) (often found in /sbin)----- it
>miscounts a timezone offset and confuses seconds with minutes or some
>such.------- get a new version of the clock program.

I wanted to find out whether this was the problem. Luckily, Harald
Hoffmann told me how to set and inquire about the kernel's internal
variable, sys_tz:

>sys_tz can be set with settimeofday().

>Try this C program:

Harald's program didn't quite work, but the failure of the clock program
to set sys_tz was indeed the cause, as gettimeofday() reported the
timezone offset as 0.

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.

-- 
Ron House            house@usq.edu.au

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

Ron House wrote:
> 
> Thanks to all the kind people who volunteered their suggestions to help
> me with this problem. I have now found the solution. It was Doug Moir
> who put me onto the right answer with this suggeestion:
> 
> >There is a bug in the program clock(8) (often found in /sbin)----- it
> >miscounts a timezone offset and confuses seconds with minutes or some
> >such.------- get a new version of the clock program.
> 
> I wanted to find out whether this was the problem. Luckily, Harald
> Hoffmann told me how to set and inquire about the kernel's internal
> variable, sys_tz:
> 
> >sys_tz can be set with settimeofday().
> 
> >Try this C program:
> 
> Harald's program didn't quite work, but the failure of the clock program
> to set sys_tz was indeed the cause, as gettimeofday() reported the
> timezone offset as 0.
> 
> 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.)

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.

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

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.

On Sun, 27 Sep 1998, Peter B. West wrote:

>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
 -u
Sun Oct  4 22:08:10 UTC 1998   

>date 
Mon Oct  5 00:03:16 CEST 1998     

>/sbin/hwclock --show
Mon Oct  5 00:05:33 1998  -0.648384 seconds        

>/sbin/hwclock --utc --show
Mon Oct  5 02:05:58 1998  -0.894695 seconds     

OK, don't care for the minutes, I got some phonecalls in between.

What do I have here? I have my BIOS on local time (which is Central European
Summer Time). During installation of Linux (SuSE 5.3, 2.0.35) I told the system
that I am in TZ Berlin/Europe and that my BIOS is showing local time.

Now with [date] I get the local time. 
With [date -u] I get UTC time which is 2 hours behind.
With [hwclock --show] I get local time. 
With [hwclock --utc --show] I get UTC time which is... WHAT NOW?

As you can see above UTC is with date 2 hours behind and with hwclock 2 hours
ahead.

I read S.Hawking's "Brief history of Time" and I managed to understand about
60% of what he writes there. But I don't understand this here my own Linux-box.

Wolfgang, lost in time....
-- 
wobo <wobo@gmx.de>
Powered by Penguin Wisdom

Wolfgang Bornath wrote:
> [snip]
> What do I have here? I have my BIOS on local time (which is Central European
> Summer Time). During installation of Linux (SuSE 5.3, 2.0.35) I told the system
> that I am in TZ Berlin/Europe and that my BIOS is showing local time.
> 
> Now with [date] I get the local time.
> With [date -u] I get UTC time which is 2 hours behind.
> With [hwclock --show] I get local time.
> With [hwclock --utc --show] I get UTC time which is... WHAT NOW?
> 
> As you can see above UTC is with date 2 hours behind and with hwclock 2 hours
> ahead.

"hwclock --utc" is incorrect.  My timezone is UTC+10; "date", "date -u" and
"hwclock" show the expected times, but "hwclock --utc" shows the time as
10 hours ahead of local instead of 10 hours behind.  Presumably the program
was written by someone in the USA who thought that UTC is always ahead of
local time.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    Paul Taylor                                Veni, vidi, tici -
    birder@ozemail.com.au                      I came, I saw, I ticked.

Paul Taylor <birder@ozemail.com.au> writes:

|> Wolfgang Bornath wrote:
|> > [snip]
|> > What do I have here? I have my BIOS on local time (which is Central European
|> > Summer Time). During installation of Linux (SuSE 5.3, 2.0.35) I told the system
|> > that I am in TZ Berlin/Europe and that my BIOS is showing local time.
|> > 
|> > Now with [date] I get the local time.
|> > With [date -u] I get UTC time which is 2 hours behind.
|> > With [hwclock --show] I get local time.
|> > With [hwclock --utc --show] I get UTC time which is... WHAT NOW?
|> > 
|> > As you can see above UTC is with date 2 hours behind and with hwclock 2 hours
|> > ahead.
|> 
|> "hwclock --utc" is incorrect.  My timezone is UTC+10; "date", "date -u" and
|> "hwclock" show the expected times, but "hwclock --utc" shows the time as
|> 10 hours ahead of local instead of 10 hours behind.  Presumably the program
|> was written by someone in the USA who thought that UTC is always ahead of
|> local time.

No, you are misunderstanding the meaning of --utc for hwclock.  It tells
hwclock to assume that the RTC is running in UTC, which obviously is not
the case for you.  It does *not* mean to display the RTC time in UTC.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

[follow-ups trimmed - this never belonged in many of these groups,
folks, please try to post more appropriately AND ALWAYS SET FOLLOWUPS.
Read new.users, huh?]

In many groups Paul Taylor <birder@ozemail.com.au> wrote:
> "hwclock --utc" is incorrect.  My timezone is UTC+10; "date", "date -u" and
> "hwclock" show the expected times, but "hwclock --utc" shows the time as
> 10 hours ahead of local instead of 10 hours behind.  Presumably the program
> was written by someone in the USA who thought that UTC is always ahead of
> local time.

No, I think the operation is correct and your expectations are wrong. 
The meaning of the UTC option is different for the two commands.  In
the case of [hw]clock (I'm used to clock, and assume hwclock has the
same interface here), rather than meaning "report the (real, kernel
notion of) the current time as UTC" as clock -u does, the hwclock
option means "report the CMOS clock's time as local time _assuming_
that the CMOS clock is actually keeping UTC time".  There's no
(standard) way for hwclock to determine whether the CMOS clock is set
to UTC or local time - you have to tell it.

You don't want to use the UTC option with [hw]clock unless your CMOS
clock actually is set to UTC rather than local time.

Paul Taylor wrote:
>Wolfgang Bornath wrote:
>> [snip]
>> What do I have here? I have my BIOS on local time (which is Central European
>> Summer Time). During installation of Linux (SuSE 5.3, 2.0.35) I told the system
>> that I am in TZ Berlin/Europe and that my BIOS is showing local time.
 
>> Now with [date] I get the local time.
>> With [date -u] I get UTC time which is 2 hours behind.
>> With [hwclock --show] I get local time.
>> With [hwclock --utc --show] I get UTC time which is... WHAT NOW?
 
>> As you can see above UTC is with date 2 hours behind and with hwclock 2 hours
>> ahead.

>"hwclock --utc" is incorrect.  My timezone is UTC+10; "date", "date -u" and
>"hwclock" show the expected times, but "hwclock --utc" shows the time as
>10 hours ahead of local instead of 10 hours behind.  Presumably the program
>was written by someone in the USA who thought that UTC is always ahead of
>local time.

RTFM.

From the man page on date
---------------
 -u, --universal

Print or set the time and date in Coordinated  Universal 
Time (also known as Greenwich Mean Time) instead of in
local (wall clock) time.
------------

From the man page on hwclock
-------------
 --utc  
 
Indicates that the Hardware Clock is kept  in  Universal
Coordinated Time.  It is your choice whether to keep your
clock in UTC or local time, but  nothing  in  the  clock 
tells which you've chosen.  So this option is how you  give 
that information  to hwclock.
--------------

---
Dave Blake
dblake@phy.ucsf.edu

In <36187FCD.774B379C@ozemail.com.au> Paul Taylor <birder@ozemail.com.au> writes:

>Wolfgang Bornath wrote:
>> [snip]
>> What do I have here? I have my BIOS on local time (which is Central European
>> Summer Time). During installation of Linux (SuSE 5.3, 2.0.35) I told the system
>> that I am in TZ Berlin/Europe and that my BIOS is showing local time.
>> 
>> Now with [date] I get the local time.
>> With [date -u] I get UTC time which is 2 hours behind.
>> With [hwclock --show] I get local time.
>> With [hwclock --utc --show] I get UTC time which is... WHAT NOW?

You can't use "hwclock --utc" when your hardware-clock is set for local time.

From 'man hwclock':

       --utc  Indicates that the Hardware Clock is kept in Universal Coordinated Time.
              It  is  your choice whether to keep your clock in UTC or local time, but
              nothing in the clock tells which you've chosen.  So this option  is  how
              you give that information to hwclock.

       If  you  don't  specify  --utc when you should, or vice versa, both setting and
       querying of the Hardware Clock will be messed up.

-- 
Henrik Storner  |  "testing? What's that? If it compiles, it is good, 
                |   if it boots up it is perfect."
                |                                    Linus Torvalds

Dave Blake wrote:
> RTFM.
> 
> From the man page on date
> ---------------
>  -u, --universal
> 
> Print or set the time and date in Coordinated  Universal
> Time (also known as Greenwich Mean Time) instead of in
> local (wall clock) time.
> ------------
> 
> From the man page on hwclock
> -------------
>  --utc
> 
> Indicates that the Hardware Clock is kept  in  Universal
> Coordinated Time.  It is your choice whether to keep your
> clock in UTC or local time, but  nothing  in  the  clock
> tells which you've chosen.  So this option is how you  give
> that information  to hwclock.

Doh! 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    Paul Taylor                                Veni, vidi, tici -
    birder@ozemail.com.au                      I came, I saw, I ticked.