----- Original Message -----
From: "valdis kletnieks" <valdis.kletnieks@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 jra@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