Re: CVS commit: src/etc

[Martin Husemann <martin%duskware.de@localhost>]

On Sat, Dec 27, 2003 at 12:02:54AM -0500, Perry E. Metzger wrote:
> Does this stuff actually work properly in the face of things like DST
> transitions?

Yes, works for me.

> The code makes the implicit assumption that the kernel's idea of the
> time has to shift when rtc_offset changes, when in fact sometimes you
> want kernel time to change and sometimes you want to do a resettodr,
> depending on *why* you are changing rtc_offset.

See the old discussion about this, starting at 

http://mail-index.netbsd.org/tech-kern/2003/04/18/0005.html

This method is not perfect for every case, and you might thing of 
circumstances different to the original target where you want the shift to
have a different effect.

In the discussion referenced above the idea spread that we would need cron
extensions to run scripts a DST start/end (or other timeshift events) and
those scripts would do the right thing (tm) - where the means for that have
not yet been provided. Noone came up with cron patches to acomplish that,
so it never happened. Please feel free to do so, and I promise to do the
kernel work to support that case too.

Basically what happens with this script now is: Windows (or AmigaOS, or others)
resets the RTC clock while NetBSD is not running, due to a DST shift. Now
we boot NetBSD - notice that the RTC offset is wrong, fix that and set the
date. Thats what you would have done manually before too.

The other case works fine for me too, but probably since I do not care too 
much for details: if NetBSD runs while DST shifts, everything still is fine,
the RTC offset stays at its old value (just like it did before) and when we
reboot to some other OS it will fiddle with the RTC clock. At next NetBSD
boot, the same things as described above happen.

Now the gotcha is: if we use rtc_offset for things like msdosfs (which we
should, but according to grep don't do yet) we'd have a period after DST 
shift where our rtc_offset is wrong (though time is right from userland
perspective), which would lead to files being created on floppys/share hard
disk partitions with one hour off. If cron could run a "fix rtc offset but
keep the date" script at such events, we would be fine.

Martin