Daylight savings time change - solution ?

Daylight savings time change - solution ?

Post by Stefan Monnie » Wed, 04 Nov 1998 04:00:00




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

Note that if you use NTP, a quick `ntpdate' at boot time will set your system
clock correctly without regard for the CMOS clock:  this way you can let
your CMOS clock for the other OS to*around with.

        Stefan

 
 
 

Daylight savings time change - solution ?

Post by Mike Dowlin » Wed, 04 Nov 1998 04:00:00


I never cease to be amazed that UNIX always seems to know when we go onto or
off dayloght savings time.  How?

I point out that the time for reverting to winter time here in Europe changed
about a year ago, yet even our HP workstations seemed to know about it, even
without an OS update.

Granted, we do use nntpd, yet nntpd refuses to modify the time if the local
time and that obtained remotely differ wildly; i.e., by more than a minute or
two.  The daemon merely exits quietly, without so much as a murmer (as i
recently witnessed again after an OS update on one of our workstations, where
the update obviously was confused about the actual time).

Cheers,
        Mike

 
 
 

Daylight savings time change - solution ?

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




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

Quote:

> I never cease to be amazed that UNIX always seems to know when we go onto or
> off dayloght savings time.  How?

> I point out that the time for reverting to winter time here in Europe changed
> about a year ago, yet even our HP workstations seemed to know about it, even
> without an OS update.

> Granted, we do use nntpd, yet nntpd refuses to modify the time if the local
> time and that obtained remotely differ wildly; i.e., by more than a minute or
> two.  The daemon merely exits quietly, without so much as a murmer (as i
> recently witnessed again after an OS update on one of our workstations, where
> the update obviously was confused about the actual time).

Put an ntpdate -b <servers> in the script *before* you start xntpd (or
nntpd, I presume is another NTP daemon?)  If you don't have ntpdate
you could use rdate.

        -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 Peter Samuels » Wed, 04 Nov 1998 04:00:00



Quote:> 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 :-).

Forgive my possible ignorance on the matter, but in general, is the
CMOS clock or the OS clock usually more stable?  I would expect the
CMOS clock to be, if for no other reason than that the OS might
occasionally miss a tick due to disabling interrupts for too long.  In
which case, if you set the CMOS clock either via cron job or via init
script, you will be buying some extra drift.  Not sure Red Hat would
want to "fix" their scripts, if that meant the system clock is less
accurate.  (Not everyone can sync with better time servers via NTP.)

The thing to do would be for the init script to check and see if the
time zone has changed since it last ran (it would use a file mtime
somewhere, maybe even "$0"...) and run hwclock if necessary.

Quote:> The right way to solve the problem is to run your CMOS clock in UTC
> time instead of localtime

Yes.  That's what I do.  But then again I have it easy since "that
other OS" is long gone from my hard disk.

--
Peter Samuelson
<sampo.creighton.edu!psamuels>

 
 
 

Daylight savings time change - solution ?

Post by Stefan Monnie » Wed, 04 Nov 1998 04:00:00



> I never cease to be amazed that UNIX always seems to know when we go onto or
> off dayloght savings time.  How?

Old systems use some timezone description in the TZ envvar.  Not very powerful,
and requires cheezy handtuning.
Newer systems use the Olson zoneinfo system where each timezone is described
in a file with the DST rules (and how they change over time:  those files had
to be updated when Europe changed its DST rules, but the old rules are still
applied for old times (and newer rules are already applied for future times)),
It's indeed pretty neat.

Quote:> I point out that the time for reverting to winter time here in Europe changed
> about a year ago, yet even our HP workstations seemed to know about it, even
> without an OS update.

The update that brought the new info was probably done "long" before, so you
didn't notice the relationship.

Quote:> Granted, we do use nntpd, yet nntpd refuses to modify the time if the local

I assume you mean "ntpd" because I fail to see why you'd suddenly switch to
discussing NetNews.  NTP completely disreagrds the issue of local time: it only
deals with UTC time and nothing else so it's completely immune to any DST
issue (and quite rightly so:  how would NTP servers running in different
timezones cooperate sanely else ?).

Quote:> time and that obtained remotely differ wildly; i.e., by more than a minute or
> two.  The daemon merely exits quietly, without so much as a murmer (as i
> recently witnessed again after an OS update on one of our workstations, where
> the update obviously was confused about the actual time).

Yes, I've been bitten by this one also.  The typical answer is "use ntpdate",
but it doesn't always cut it:  if you're disconnected from the rest of the
world at boot time, ntpdate might fail (as well as hang stupidly because
although it is careful to quickly time out when the servers are unavailable, it
just uses the standard resolve library and hence might have to wait for
the DNS request to (oh so slowly) time out).

It really seems that xntpd should have a better failure mode.  For instance, if
the local time is too far from UTC, instead of silently failing, it could do
the equivalent of what ntpdate does (and keep trying until it works).

Or it should at least be possible to ask ntpd to exit with an informative error
code, so that we get a chance to do something like

        until ntpd; do ntpdate; done

The current behavior is very annoying since it's surprisingly hard to detect
the failure.

        Stefan

 
 
 

Daylight savings time change - solution ?

Post by Peter Samuels » Wed, 04 Nov 1998 04:00:00



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

That *is* a good one.  At least with Linux you *can* work around these
things easily enough, as the rest of your post demonstrates.

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

Very clever.

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

I just investigated a little.  Looks like for NT you just have to change

-if ( m/\x0e\x00\x04\x00ActiveTimeBias(....)/s ) {
-  printf "GMT%+d\n", -unpack("l",$1)/60;
+if ( m/(....)........ActiveTimeBias/s ) {
+  printf "GMT%+d\n", unpack("l",$1)/60;

where all those dots in the RE probably should be hex characters like
yours only I don't feel comfortable reverse-engineering the file format
to the point of specifying meaningful values.  I figure false positives
will still be low.

According to /usr/share/misc/magic, you can tell an NT registry because
it starts with "regf".  Perhaps the Perl program should use that to
decide which format it is looking for, unless for some reason doze95
uses the same string (then you'd have to pass in a filename and check
it for "*.DAT"...).

--
Peter Samuelson
<sampo.creighton.edu!psamuels>

 
 
 

Daylight savings time change - solution ?

Post by bill davids » Wed, 04 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.

In other words, you made a poor decision to run your hardware clock not
only in local time instead of uct, but set it to daylight savings time.
Then you complain that Linux didn't correct for your poor decision.

You avoid all this by keeping the clock in uct, as explained in various
man pages, install guides, howto's, etc.
--

 The young confuse living a long time with getting old,
 the old confuse age with maturity.

 
 
 

Daylight savings time change - solution ?

Post by David F » Wed, 04 Nov 1998 04:00:00



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

An alternate solution to your problem is to move your account to a
web-friendly bank like Bank of America or Citibank.   :)
--
David Fox           http://hci.ucsd.edu/dsf             xoF divaD
UCSD HCI Lab                                         baL ICH DSCU
 
 
 

Daylight savings time change - solution ?

Post by Ron Forreste » Wed, 04 Nov 1998 04:00:00


Quote:> An alternate solution to your problem is to move your account to a
> web-friendly bank like Bank of America or Citibank.   :)

My bank (credit union actually) is very web friendly. can view my
account (cleared charges, etc), transfer money, automatically pay bills,
etc.

However, this doesn't really help to automate the 'balancing' portion of
managing bank accounts. I would still have to compare by hand my web
statement with my electronic register. This is error prone and a real
hassel, and I basically refuse to do it (having tasted how easy
automation makes it).

Any more on this subject, lets take it offline or to another group...
Thanks.
rjf&