Daylight savings time change - solution ?

Daylight savings time change - solution ?

Post by Arun Sharm » Sun, 01 Nov 1998 04:00:00



I was a little bit annoyed last weekend, when my brother's computer
running windows adjusted the daylight savings time correctly and mine
didn't because it had to be rebooted because it was powered down
accidentally.

I played around with it a bit and noticed that the system date changes
automatically using the info in /usr/share/zoneinfo, but the CMOS
clock doesn't change, unless somebody does hwclock --systohc.

One suggested solution is to set the hardware clock to UTC, which'll
solve the problem. But most Linux users also have the "other" OS on
their computer and someone correct me if I'm wrong - the other OS
requires that the hardware clock is set to the local time.

Possible solutions:

1. Shutdown scripts transfer the system clock to the hwclock before
   reboot. I don't see this happening currently on my Redhat 5.1
   system. The problem with this approach is that it doesn't take care
   of the situations in which the machine is shutdown abnormally.

2. Have a cron job which wakes up at 2 am everyday and checks for the
   daylight saving time change and does hwclock --systohc. This
   solution will work only if the change happens at 2am in all
   countries. But this still doesn't work if the machine is down at
   that time and powered up at a later point in time.

3. So the correct solution IMO, should save the timestamp somewhere on
   the disk on shutdown and on reboot, initscripts should check if
   there has been a correction since the last reboot and correct the
   time automatically. Additionally, a cron job should be scheduled to
   take care of the case where the system is up at the time when the
   change occurs and should be responsible for transferring the system
   time to hwclock.

Comments, suggestions ?

        -Arun

 
 
 

Daylight savings time change - solution ?

Post by H. Peter Anv » Mon, 02 Nov 1998 04:00:00




In newsgroup: comp.os.linux.development.system

Quote:

> One suggested solution is to set the hardware clock to UTC, which'll
> solve the problem. But most Linux users also have the "other" OS on
> their computer and someone correct me if I'm wrong - the other OS
> requires that the hardware clock is set to the local time.

No.  The "other OS" require your hardware clock to be set to *local
time last time the "other OS" was run*, because it expects to frob the
clock if a DST change has occurred since last it was run.  Yes, this
is incredibly broken, but we all know who we are talking about...

There is pretty much no way to make that operate sanely.  *Sigh.*

        -hpa
--
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah' -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misrables

 
 
 

Daylight savings time change - solution ?

Post by Ron Forreste » Mon, 02 Nov 1998 04:00:00



> No.  The "other OS" require your hardware clock to be set to *local
> time last time the "other OS" was run*, because it expects to frob the
> clock if a DST change has occurred since last it was run.  Yes, this
> is incredibly broken, but we all know who we are talking about...

Well, I *used* to run the NT version of the "other OS". Now I am running
Linux
and was running it last week (in the PST zone) when the change it. I was
pretty
happy when I woke up and flipped the monitor on (my box runs 24x7) and
the time
had changed correctly. The other OS did so last year as well, so I was
glad that
I hadn't lost anything in the transistion -- or so I thought.

I did some kernel recompiling that day (adding a couple of drivers as
modules),
which necessitated a reboot to get the new kernel running. When I came
back into
Linux, the clock was wrong, one hour ahead. It seems Linux had not set
my bios
time. So, I su'ed and used 'date' to set it back, a little miffed that I
had to
do this. Did a couple of other things and rebooted again, and again my
time had
jumped back ahead an hour. Damit. So I rebooted, jumped into the BIOS
and reset
the time correctly. End of problem.

Why didn't Linux do this for me? The "other OS" did last year. I am
running
2.1.124, so perhaps this is a bug in the 'unstable (not)' kernel that I
need to report?

Any info?
rjf&

 
 
 

Daylight savings time change - solution ?

Post by Todd Knar » Mon, 02 Nov 1998 04:00:00



> Why didn't Linux do this for me? The "other OS" did last year. I am
> running
> 2.1.124, so perhaps this is a bug in the 'unstable (not)' kernel that I
> need to report?

The system only reads the CMOS clock on startup, it never updates it. In
fact, the kernel doesn't even read the CMOS clock. If you check in
/etc/rc.d/rc.sysinit, you'll find the clock/hwclock command that sets
the system time from the CMOS clock there. There are a couple of options
to force the CMOS clock to be updated from the system clock:

1. Run the xntp daemon. This has other effects, good and bad.
2. Add appropriate lines to rc.local to use clock/hwclock to update the
   CMOS clock on shutdown, or create a startup/shutdown script to do this
   similar to the ones that start and stop other services.
3. Set up a cron job that updates the CMOS clock using clock or hwclock
   on a regular basis ( perhaps daily at about 3:30 am to keep it clear
   of DST changes ).

--
Don't worry about where to land -- by the time you get to it, it
_will_ be flat.
                                -- concering Orion landing procedures

 
 
 

Daylight savings time change - solution ?

Post by Stefan Monnie » Mon, 02 Nov 1998 04:00:00



> I did some kernel recompiling that day (adding a couple of drivers as
> modules), which necessitated a reboot to get the new kernel running. When I
> came back into Linux, the clock was wrong, one hour ahead. It seems Linux had
> not set my bios time. So, I su'ed and used 'date' to set it back, a little

Indeed, Linux only sets the minutes and seconds of the CMOS clock and this only
if you're running something like NTP.  Apart from that, the kernel never
touches the CMOS clock.

Reading and setting the CMOS clock is done via user tools like hwclock which
are supposed to be run at startup(read) and shutdown(write).  RedHat does run
hwclock at startup but isn't smart enough to run it at shutdown which means
that your hwclock's hours are never reset.  Go bug RedHat so they fix their
scripts.  Or ask me for my boot scripts :-).

The right way to solve the problem is to run your CMOS clock in UTC time
instead of localtime (which might require you to set some variable somewhere so
the boot scripts know how to set the system clock from the CMOS clock.? Check
out /etc/sysconfig/clock if you use RedHat).

        Stefan

 
 
 

Daylight savings time change - solution ?

Post by Preston Cro » Mon, 02 Nov 1998 04:00:00



> The system only reads the CMOS clock on startup, it never updates it. In
> fact, the kernel doesn't even read the CMOS clock. If you check in
> /etc/rc.d/rc.sysinit, you'll find the clock/hwclock command that sets
> the system time from the CMOS clock there.

That's technically not correct.  Before the kernel executes any of the startup
scripts, the date is set based on the CMOS time, assuming that the CMOS is set
to UTC.  All the [hw]clock command does is patch up the time zone issue.  If
your clock is in UTC to begin with, you never need to worry about any clock
reading or writing functions in any startup or shutdown scripts (though you
might want to run xntp to prevent clock drift).

The problem is that you can't tell Windows that your clock is set to UTC,
unless you're happy having the runtime clock also set to UTC.

Also, if Linux patches up the hardware clock as a result of switching to
darkness savings time, the next time Windows boots, it will try to shift the
clock yet again.  (Maybe some Windows hacker should explain here how Linux
could mount the Win31/95/NT partition and trick Windows into thinking that it
had already taken into account the time change.)

So if we assume that the hardware clock is set to local time, how should Linux
behave when it detects an hour shift, so as to minimize confusion with Windows?
If you can figure out how you want it to behave, then you're half way there.
Unfortunately, I don't see that it is obvious what the best behaviour is.

--PC

 
 
 

Daylight savings time change - solution ?

Post by H. Peter Anv » Tue, 03 Nov 1998 04:00:00




In newsgroup: comp.os.linux.development.system

Quote:

> The problem is that you can't tell Windows that your clock is set to UTC,
> unless you're happy having the runtime clock also set to UTC.

It seems that the Right Thing is for someone to write a patch to set
the Windoze clock from an UTC realtime clock...

Someone knows a Windoze hacker of merit?

        -hpa
--
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah' -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misrables

 
 
 

Daylight savings time change - solution ?

Post by Bob Hau » Tue, 03 Nov 1998 04:00:00




[Linux didn't handle setting BIOS clock at DST change]

Linux doesn't change the BIOS clock at the changeover from DST.
All good Unix boxes keep their hardware clocks on GMT anyway, so
there is no need to fiddle with it.  If you do it that way, Linux
handles the whole deal just fine.

 
 
 

Daylight savings time change - solution ?

Post by Todd Knar » Tue, 03 Nov 1998 04:00:00



> Also, if Linux patches up the hardware clock as a result of switching to
> darkness savings time, the next time Windows boots, it will try to shift the
> clock yet again.  (Maybe some Windows hacker should explain here how Linux
> could mount the Win31/95/NT partition and trick Windows into thinking that it
> had already taken into account the time change.)

Or better yet, just hack Windows to use the CMOS clock in UTC time. Or do
what I do and have a box running only Linux with a UTC hardware clock,
disable DST adjustment on all other boxes and have them slave their clocks
to the Linux box via NTP or the like. End of DST problems, end of a number
of Y2K problems where the OS is fine but the BIOS can't handle it, end of
serious clock skew, end of a lot of headaches in general ( unless someone
fscks up tick and tock, which isn't unheard-of either ).

Quote:> So if we assume that the hardware clock is set to local time, how should
> Linux behave when it detects an hour shift, so as to minimize confusion
> with Windows? If you can figure out how you want it to behave, then you're
> half way there. Unfortunately, I don't see that it is obvious what the
> best behaviour is.

I don't think there is a best behavior. Any time you have two OSes on the
same hardware and a hardware clock ticking in local time, you have to keep
all but one of them from adjusting for DST. Unfortunately none of them have
any way of telling the others which one it should be. IMHO the best thing
I can come up with is "the OS adjusts to DST _only_ when it actually crosses
the time, and only once in a row in a given direction, otherwise it assumes
someone else has handled it". You have to manually set things if the box
is shut down during the changeover, but at least the problem is manageable.

--
Don't worry about where to land -- by the time you get to it, it
_will_ be flat.
                                -- concering Orion landing procedures

 
 
 

Daylight savings time change - solution ?

Post by Nick Andr » Tue, 03 Nov 1998 04:00:00



Quote:>I don't think there is a best behavior. Any time you have two OSes on the
>same hardware and a hardware clock ticking in local time, you have to keep
>all but one of them from adjusting for DST.

Obviously if the clock is set in UTC and whichever OS is running uses
an offset (i.e. not updating the RTC directly) to determine local time,
that's best behaviour.

Alternately if the clock is in local time and neither OS updates it, that's
also best behaviour.

The clock is a shared resource and unless 2 (or more) OSs can arbitrate on
correct update, neither OS should update the clock.

Nick.
--
Zeta Internet                     SP4   Fax: +61-2-9233-6545 Voice: 9231-9400
G.P.O. Box 3400, Sydney NSW 1043        http://www.zeta.org.au/

 
 
 

Daylight savings time change - solution ?

Post by Brian McCaule » Tue, 03 Nov 1998 04:00:00



> One suggested solution is to set the hardware clock to UTC, which'll
> solve the problem. But most Linux users also have the "other" OS on
> their computer and someone correct me if I'm wrong - the other OS
> requires that the hardware clock is set to the local time.

> Possible solutions:

[snip]

Quote:> Comments, suggestions ?

The trouble with all Arun's solutions is that they fail because the
other OS (let's call it Win95) will still apply the time "correction"
next time system is booted into Win95.  Arun's solutions seek to
emulate the broken Win95 behaviour rather than consider it a problem
to be worked arround.

(BTW FYI: Arun, AFAIK in the EU the change happens at the same instant
(1am UTC) across all counrties, not the same localtime.)

(BTW2: In a bit of poetic justice this problem actually hits
Win95/WinNT dual-boot harder than Win95/Linux dual boot.)

The solution is to do what Win95 actually wants.  Obviously Win95
can't adjust the clock while the machine is switched off.  So on a
Win95 only machine has a CMOS clock not actually stored in localtime
but in "whatever timezone was local last time Win95 was running".  The
logical extension of this behaviour to the dual boot situation is to
have Linux leave the CMOS clock alone and simply figure out what
timezone it is stored in by reading the Win95 registry.  To do this
I'd use the attached script.  This works with the old "clock" program
but not with its replacement "hwclock" as the latter ignores the
setting of the TZ environment variable.

I have not looked at the issue of reading the NT registry from Linux.

#!/usr/bin/perl
# Get current timezone of hardware clock on machines that also run Win95.
#
# Not totally bullet-proof as the byte sequence could appear out of context.
# Only handles integer timezones.
#
# Usage:
#  TZ=$(get-windows-tz </DOS/windows/system.dat) clock -s
#  TZ=$(get-windows-tz </DOS/windows/system.dat) clock -w
#
# Since this is rather slow you may like to write it to a file if
# you use something like "ntpdate" to update your clock.

until(eof STDIN) {
  read STDIN,$_,1024,(length)+1;
  if ( m/\x0e\x00\x04\x00ActiveTimeBias(....)/s ) {
    printf "GMT%+d\n", -unpack("l",$1)/60;
    exit;
  }
  $_=substr($_,1025) if length > 2000;

Quote:}

--

  .  _\\__[oo   faeces from    | Phones: +44 121 471 3789 (home)

 .  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
  # ll  l\\  ~~~~ ~   ~ ~    ~ | http://www.wcl.bham.ac.uk/~bam/
 ###LL  LL\\ (Brian McCauley)  |
 
 
 

Daylight savings time change - solution ?

Post by Stefan Monnie » Tue, 03 Nov 1998 04:00:00



> 1. Run the xntp daemon. This has other effects, good and bad.

This has no impact on the hours of the CMOS clock.  Only minutes and seconds.

        Stefan

 
 
 

Daylight savings time change - solution ?

Post by Jürgen Exne » Tue, 03 Nov 1998 04:00:00




>> I did some kernel recompiling that day (adding a couple of drivers as
>> modules), which necessitated a reboot to get the new kernel running. When
I
>> came back into Linux, the clock was wrong, one hour ahead. It seems Linux
had
>> not set my bios time.

Well, why should it change the CMOS clock?
The CMOS clock should run UTC, which by definition does not have a daylight
saving time.

jue
--
Jrgen Exner; microsoft.com, UID: jurgenex
Sorry for this anti-spam inconvenience

 
 
 

Daylight savings time change - solution ?

Post by Ron Forreste » Tue, 03 Nov 1998 04:00:00


Quote:> Well, why should it change the CMOS clock?
> The CMOS clock should run UTC, which by definition does not have a daylight
> saving time.

As outlined my many others already, I am in the VERY unfortunate
position of
having to occasionally run the "other OS", currently ONLY to do my
online banking
(come-on GNU-Cash, get that implemented ;-). The 'other OS' don't take
kindly to
UTC.

So, until I can erradicate the "other OS" from my system, I guess I am
stuck with
having to manually set the time once a year. Oh well.

rjf&

P.S. When you all say set the CMOS clock to UTC, I assume you mean to
just set
the time as if it were UTC, not that there is a flag in my BIOS which
indicates
I am using UTC time -- apologies for the ignorance.

 
 
 

Daylight savings time change - solution ?

Post by Todd Knar » Wed, 04 Nov 1998 04:00:00



> Alternately if the clock is in local time and neither OS updates it, that's
> also best behaviour.

Which results in the switch never being made unless the admin does it by
hand which is NP-annoying.

--
Don't worry about where to land -- by the time you get to it, it
_will_ be flat.
                                -- concering Orion landing procedures