----- Original Message ----- > From: "valdis kletnieks" <valdis.kletni...@vt.edu>
> When the published API has been "the system clock is in UTC" for some 3 > decades, I hardly think it's acceptable to call apps "buggy" for assuming that > the system clock is in fact using UTC and breaking if you switch it to > something that's not UTC. And the new time *has* to have different semantics > than UTC, because if it doesn't then what's the point of changing it? Correct. It's very likely that there is *no* sufficiently compelling application requirement that justifies switching NTP from UTC to UT1/TAI. So far as I can tell, the *only* requirement is "I need to be able to calculate unixtime<->ISO8601 reliably to the second for times further away than the next possible leapsecond"; I have not had pointed out to me yet an application which actually requires that; I'm 99 44/100% certain that there isn't one with a sufficiently compelling story to break 3 decades of code. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
