Tony Finch wrote: >Are there any APIs which have an explicit variable epoch, and which reset >the clock by adjusting its epoch instead of its counter? This would >eliminate the need for seperate interval and real-time clocks.
Interval clock and real-time clock remain conceptually distinct. If you have a single clock counter alongside a variable epoch, the sum of the two is the effective real-time clock. I don't think you're gaining anything by not reifying it. Where this concept wins is as an implementation strategy. When adjusting the counter of a PC RTC, for example, there is a problem of knowing whether you've done the adjustment when you reboot. There are well-known problems with DST adjustments being performed twice, by the same or another OS, but the same kinds of problems arise even without attempting to reflect DST in the clock. If you're collecting data on how far out the clock is and adjusting the clock accordingly, upon a reboot you can't tell whether you have made the latest adjustment. Two OSes sharing the machine don't know about each other's adjustments. The solution is to just let the clock run, never adjust it, and treat it as an independent seconds count. You don't care about it showing the wrong time, because you don't treat its output as an absolute time. Instead, collect your data on how far out it is (or rather, what absolute time -> output function it is computing) and add the epoch in software. Any number of users of the same clock can do this without treading on each other's toes. I don't know of any implementation of this strategy for the PC RTC. I'll be doing one myself sometime soon, as I'm developing an OS in my spare time. -zefram