On 1/20/2012 7:13 AM, Tim Bray wrote: > One consequence of your proposal, if adopted, is that there will need > to be a specification of the canonical Internet-time-to-Sidereal-time > function, No actually there isn't such a need Tim. Its one of the problems we face here in the timekeeping world. In fact let me respond as a professional timekeeper since it appears as I am the only one here. > so that in the long run, the time that your computer says it > is will correspond with what you observe looking out the window. OK - I disagree. Global time should not be local time. If people are too stupid to deal with that wait another 30 yeas and those idiots will all be gone... as in dead - and the new crop of talent will have grown up with the fact that time is mutable. The issue of the Internet being around you cite below also pertains to space based commerce, so in designing a system that only works on this planet you repeat the previous mistake. The > Internet will be around long enough that this will indeed become a > problem. So again the issue here is that protocols and software today are implemented to need this support. That is the way were designed, i.e. in a manner which specifically causes this thing now being identified as a problem. > > On Fri, Jan 20, 2012 at 6:20 AM, Phillip Hallam-Baker <hallam@xxxxxxxxx> wrote: >> If we are ever going to get a handle on Internet time we need to get rid of >> the arbitrary correction factors introduced by leap seconds. OK I can see this. Why cannot the Internet track TAI and a TAI to real-world offset table be kept and published by NIST, NPL, PTB, NRC, NITC or how about from NTP.ORG for instance... its their protocol right? Seems simple to make the client-side of the NTP implementation totally responsible for the time conversion if its even necessary. That's a reference port change and not a protocol change per se as well meaning it doesnt take the IETF to approve that at all. >> >> The problems caused by leap seconds are that they make it impossible for two >> machines to know if they are referring to the same point in future time and >> quite often introduce errors in the present. No... they just require something more than the limited use time synchronization tools around today like NTP for instance. >> >> 1) No machine can determine the number of seconds between two arbitrary UTC >> dates in the future since there may be a leap second announced. >> >> 2) If Machine A is attempting to synchronize with machine B on a future >> point in time, they cannot do so unless they know that they have the same >> view of leap seconds. If a leap second is announced and only one makes the >> correction, an error is introduced. Yes but is a failing of NTP... not leap seconds. >> >> 3) In practice computer systems rarely apply leap seconds at the correct >> time in any case. What you mean is that the time-keepers rarely apply the leap second properly. Time in the production world comes from automated sources in most instance so this is a non-issue. >> There is thus a jitter introduced around the introduction >> of leap seconds as different machines get an NTP fix at different points in >> time. Oh that's funny. Jitter introduced into a system which is not attesting to anything, or otherwise tied to most global commerce. What could this 'jitter' actually do? >> >> 4) Even though it is possible to represent leap seconds correctly in >> standard formats, doing so is almost certain to exercise code paths that >> should be avoided. >> >> >> Since the ITU does not look like sorting this out, I suggest we do so in the >> IETF. There is no functional reason that Internet protocols should need leap >> seconds. I suggest that this may cause a rift between the IETF and other Global Standards Orgs and that its something that shouldn't happen here. I also suggest that this is outside the IETF's charter or scope of operations and that it can be fixed inside the NTP working group as a design issue before being submitted to the IETF for cannonization. >> >> I suggest that the IETF plan to move to Internet Time in 2015, immediately >> after the next ITU meeting. I suggest that Internet Time should be pure TAI and simply be a standardized counter of offset (TAI offset) from the EPOCH and that anyone supplying time to the world will need a method of specifying whether its adjusted for Earth Offsets and Time of Day or whether its pure TAI. Internet time would be TAI plus the number of >> leap seconds that have accumulated up to the next ITU decision point. NO - Again - the Internet Time should be pure TAI. Securities Trading Time should be pure TAI. Financial Transaction Time should be pure TAI. So if >> UTC drops leap seconds at the next meeting the two series will be in sync, >> otherwise there will be a divergence. It is OK for them to be different values. >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf >> > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf