Subject: Re: clock problem ...
To: Steven M. Bellovin <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/28/2000 10:45:53
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.)
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!