On Mon, 2016-12-26 at 11:57 -0500, Joseph Gwinn wrote: > > > John Sauter ([email protected]) responded: > > > > Thank you for your comments, Joe. > > > > I agree that POSIX defines its own time scale for time_t, but that > > is > > not how it is being used. Everyone sets their computer’s clock to > > UTC, > > no matter what the standard says, and no matter how many seconds > > have > > passed since 1970-01-01T00:00:00Z. > > Many but not all people set their clocks to UTC. See my item 3 > above. > > Probably the majority of computer users never heard of UTC.
Sorry, that was an over-simplification on my part. I should have said "almost everyone" since you described a case in which the time was deliberately set to a non-UTC time scale. In addition, I should have said that almost everyone sets their clock to a time "based on" UTC, specifically their local time. They also set their computer's time zone variable to their local time zone. > > > I have long heard that a design goal of POSIX was that it be > > functional > > in an isolated system, but I am not sure what that really means. A > > totally isolated computer might as well be switched off, since > > nothing > > communicates with it. > > Yes, that is a major goal. Isolated means just that. Think of a > computer system at the bottom of a mine, or in a submarine. Most > such > computers do not need to know UTC - local time is adequate. > > > > That isn’t a reasonable meaning for “isolated” > > in this context, so what, really, is an isolated computer? Perhaps > > it > > means a computer with a very limited set of sensors for input, and > > a > > very limited set of effectors for output. If that is the case, > > surely > > one of the sensors can be a GPS receiver so the computer can keep > > its > > clock accurate. If not, then perhaps the computer’s clock doesn’t > > need > > to be accurate, and therefore has no need to update its leap second > > table. > > In many systems, the GPS signal is simply not available, so a GPS > receiver would be useless. > > And, as you mention, many sensors don't need to know UTC (or TAI or > anything else) - local system time is adequate. Time since last > boot-up is very common in such applications - see section 4 above. > > > > However, if a computer is going to track the Sun across the > > sky, it will need access to astronomical data, because the position > > of > > the Sun in the sky cannot be predicted to within a second five > > years in > > the future. Realistically, an “isolated” computer needs whatever > > inputs are required for it to do its job, and that might include > > the > > time. > > Systems that need to track the Sun this will provide GPS or the > like, > to be able to perform their mission. It does not follow that all > systems have any need of astronomical data. Usually, self- > consistency > and stability are the big requirements. > > > > The TAI time scale was synchronized to UTC when it was created in > > 1958, > > and has since not counted leap seconds. Similarly, the Navstar GPS > > system was synchronized to UTC in 1980 and has since not counted > > leap > > seconds, making GPS time a fixed offset from TAI. GPS receivers, > > like > > your radar systems, convert to UTC when displaying time. The > > Navstar > > GPS satellites are informed of an upcoming leap second, and pass > > that > > down to the receivers, so they can display UTC correctly. I > > suppose > > your radar systems do the same. > > Depends on application. Not all will display UTC. In many radar > systems, the GPS receiver is instead configured to emit GPS System > Time, not UTC, to avoid leap seconds. See section 3 above. Perhaps I misunderstood. I thought you said that the internal time was converted to UTC for display. Perhaps some, but not all, radars do that? > Also note that many large radar systems have built-in simulators, > used > for system integration during development and for training > thereafter. > Such simulators need to be able to work using system time that is > not > the present, say to rerun recorded observations or to simulate > future > or past scenarios. In both cases, the GPS receiver does not know > the > correct leap second offset to use. The usual solution is an > application-provided table all past leap seconds, plus the next leap > second (if known). The table is updated manually. That sounds like a fine solution. It would be nice if the table were maintained by the group of people who needed it, so that everyone wouldn't have to update his own table. > > > Your description of a typical radar > > system in part 4 is even simpler: just a count of seconds since its > > Epoch, converted to UTC for display. I am not clear from your > > description how the transition is made from NTP distributing GPS > > time > > as though it were UTC, to an internal seconds counter. Were you > > describing different radar systems? > > Yes, sections 3 (modern) and 4 (historical, but many still in use) > do > describe different systems. > > > > You may not have seen this reference from an October posting in the > > leap seconds mailing list: > > > > <http://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf> > > I had read this in October 2016, and reread it yesterday. It does > not > solve the problem of isolated systems with local clocks, systems > with > no access to the sky. I agree. I was suggesting the NISTDC as a robust and accurate replacement for a GPS receiver. > > > The NIST Disciplined Clock outputs one pulse per second with > > astonishing accuracy. I dare say it would be good enough to > > provide > > clock to a radar facility. The pulses are nameless, and hence do > > not > > suffer from leap seconds. > > We get a 1PPS pulse train from GPS receivers, and also from Cesium > clocks. Cesium works better in isolated systems. > > As others have mentioned, there is a vast existing base for POSIX > time, > so there is zero chance that time-t will become UTC. Unless the > leap > seconds are elided from UTC, as was proposed and shelved at the ITU. I agree that POSIX time_t will not become UTC. That is why I advocate not using it. > Understand that by policy, POSIX only codifies existing practice, so > the usual path is that something non-standard is added by various > vendors and over time becomes widely used, often in a flock of > similar > forms, some more widely supported than others. Then the POSIX WG > comes > along and codifies the common part of the various forms, usually > weighted by market prevalence. > > A more likely scenario is thus to define a new kind of Named Clock > in > POSIX, and wait to see if the world uses it. If yes, eventually it > will become part of the standard, and the other clocks will drift > into > obscurity. Understand that this process is glacial. > Joe Gwinn I think a new named clock would be a fine idea. Asking for the current time using the new clock could return time_t just like CLOCK_REALTIME, but return nanoseconds + 1e9 during a leap second. That could be decoded into a tm structure and also used in file systems for access time, modification time and creation time. Yes, the process is glacial, but slow progress is better than no progress. John Sauter ([email protected]) -- PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
