Hey Jeff, Think of, for example, a global network of sensors measuring geo-physical phenomena. They need to be synchronized. The maximum uncertainly is determined by the phenomenon being measured.
It all boiled down to needing a time server on port 80 whose difference from UTC was less than about 500ms. I really didn't want to use the usual port 13 servers. So I wrote a GAE time server. Three years have past since I last looked at this issue.<https://groups.google.com/forum/?fromgroups#!topic/google-appengine/wNFhGaIUlXQ> All the data I have collected show that GAE's server's are well within 500ms of UTC(NIST). Even without 'guarantees.' That's good enough for me. But today I learn that App Engine has a cool, clever workaround that slowly slews it 1 second off UTC(NIST). It's not the length of the individual seconds (frequency) that counts. It's the integral of all these seconds (phase) that matters. That integral in this case will be an error of 1 second. Next time the ERS demands a leap second, the error will be 2 seconds. This leads to a time stamp that no longer accurately reflects statements like: "Number of seconds since 1 Jan 1970 00:00:00 UTC." I'm just heart-broken to hear that Google decided to brush these leap seconds under the rug by changing the rate of their time-scale. They are real points on the UTC time-scale, and important things happen on our planet during these leap seconds. The punchline is that I did some poking around and found a buddy that serves UTC(NIST) on port 80. Sweet! David -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/hu46XeVMmb8J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
