Richard B. Gilbert <[email protected]> wrote: > The clock CHIP is not the problem. The problem is that the quartz > crystal that provides the "tick" is usually one that failed quality > control at a wristwatch factory.
The issue under discussion is not the accuracy of the clock, but the "fact" that it does not provide the year, only month/day/h/m/s. I don't know about a chip that does not provide the year, but probably it existed in some obscure computer more than 20 years ago. I know the chip used in early PCs had only 2 year digits and thus could not provide the century information, but I consider this a non-problem as it can be easily worked around by having some threshold value above which the year is considered in the past century (e.g. 80). Defending silly algorithms in code with limitations in old hardware no longer in use in running systems seems a bit silly to me. But I often recognize a pattern where people who operate ntpd in different environments than the one envisioned by the author get turned away when suggesting changes. We all know the discussions about systems not running 24h/day, systems with instability related to temperature that changes over a day/night pattern, arbitrary nonconfigrable limits on clock drift, initial clock offset etc. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
