Date: Tue, 3 Jan 2006 17:17:52 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: current@freebsd.org Subject: Re: FreeBSD handles leapsecond correctly Message-ID: <20060103061752.GE42228@cirb503493.alcatel.com.au> In-Reply-To: <20060102.221046.75255380.imp@bsdimp.com> References: <73774.1136109554@critter.freebsd.dk> <m3psnaenl9.fsf@merlin.emma.line.org> <20060102.221046.75255380.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2006-Jan-02 22:10:46 -0700, M. Warner Losh wrote: >The biggest problem with compiling leap seconds into this is that you >can only be sure that leap seconds are right for at most 6 months. >Sure, you can make statistical statements about how likely a leap >second is or isn't going to be, but this non-determinism is a big >problem. There's no way you can deploy a system and have a sane leap >second table without a connection to the outside world... The Islamic calendar is based on lunar _sightings_: If it's cloudy, the calendar shifts a day. This wreaks even more havoc than the odd leap-second and many Islamic countries have therefore switched to using almanac based dates. Actually, I'd suggest that you can't build a system that keeps any sort of accurate time without a connection to the outside world or a quite substantial budget. If you assume a leap second every 5 years then the difference between UTC and TAI is about 6e-9 - being able to tell the difference requires an atomic clock - which isn't common in embedded systems. >Leap seconds are hard and I hate them. Which of the competing alternatives would you prefer? -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060103061752.GE42228>