In message <20000125232500.1E71C41F16@SIGABA.research.att.com>
"Steven M. Bellovin" writes:


>Oh.  I confess -- if I'd written the code, it would apply rfc_offset on all 
>references to the software copy of the clock, rather than just being applied 
>when the hardware value is copied over at boot time.  That makes it much more 
>useful when coping with the drain-bamaged Other System many people have to use
> 
>on occasion.  It would let you have one kernel, rather than two, and it would 
>permit some smart user-level code in rc to decide what the offset was, given 
>daylight time, etc.  (I realize that that can't do a perfect job, especially 
>if one reboots around 2am on the two days a year when it matters, and I fully 
>agree that Windows handles that (among many other things) in a fundamentally 
>wrong fashion.  But there's not much I can do about that, and two of the three
> 
>NetBSD machines in my house run Windoze most of the time.)


Steve,

I think I see what you're getting at. But tehre's a better way to do
it.  Some two, three years ago, Dennis Ferguson[*] of ntpv2 source-code fame
sugggested re-engineering NetBSD's system clock to better handle time jumps.

Dennis' idea was to keep time as `UTC at boot' and `time since boot'.
Jumping the time would be implemented by changing the `UTC at boot',
which apart from timejumps, is otherwise readonly after booting).

That eliminates a lot of hair with timer queues and large time-jumps,
at the cost of some changes in semantics. But for this problem, it
seems exactly right.

But re the two hours when things matter: surely we can get even that
right, if we look at NetBSD filesytem times?


[*] I hope I have the name right!