March 1987 - tz - lists.iana.org

AT&T clock
by seismo!cbpavo.MIS.OH.ATT.COM!mark March 22, 1987

March 22, 1987

I am unaware of any master clock in AT&T used for sync. I do know that it's quite common for the clock in each central office to run at a significantly different rate. The symptom of this is that when you dial 1200 baud from one CO to another, you get a burst of noise on a regular basis - the frequency depends on how close the clocks are. Each time it slips one full tick, there's a phase shift, and with 212 protocol a phase shift turns into a garble. The problem occurs with the newer ESS switches. Mark

1 0

Re: extending the time range
by Chris Torek March 22, 1987

March 22, 1987

All of the proposals I have seen have `RETROFIT' stamped upon them in garish glowing ink. None seem very pretty. Instead of a retrofit, it seems to me one should define a new type, at least 64 bits wide, measured perhaps in microseconds. localtime &c should be renamed, and changed work on these new time values; compability routines would transform old `time_t's to new values, and then return the value returned by the new routines. Chris

1 0

interesting clock sync facts
by seismo!nbires!vianet!devine March 22, 1987

March 22, 1987

To change the topic from the "time_t doesn't work for everything" series of messages here is a note on about synchronizing clocks. And about the limitations of time_t, it is something we can live with. Any extensions should be extensions and not modification to time_t. Too breakable. This has nothing at all to do with Posix, but, I thought that this group might like to hear about it. Ignore if you want. If the wording seems strange at times, bear with it. This was written in a stream of consciousness mode. Note that there are many interesting algorithms described in the OS literature about clock synchronization. Dave Mills has been playing in the real world (TCP/IP connected machines) on how to synchronize clocks. He found that human error accounts for a lot of the problem (as is: "ahhh, was that supposed to be 'AM' or 'PM'?"). ---- Suppose you have N clocks that you would like to synchronize. How would you do it? The answer is "it depends". That is, it depends on how much money you want to spend and how closely synchronized you want the clocks to be. You can see that if you only want to spend one postage stamp, the best you can achieve is +/- several days (the time it takes the mailperson to deliver the letter containing a timestamp). If you cough up some bucks for two modems, you can do better. Etc. What do I mean by synchronization? The best explanation that I've come up with is: consider how the Air Force's precision flying team puts on a show. What matters to them is, first, how tight the formation is, and second, where the planes are with respect to some ground-based marker. Translating that example into clocks shows that clocks can be very close to each other (== synchronized) but still give the incorrect time (!= universal time). Sometimes synchronization is more important than correctness (distributed databases that use timestamps are an example). To get synchronization of clocks AND correctness calls for two things. A mutually agreed upon reference time source supplies the correct time. A convergence algorithm used between clocks supplies the synchronization. Here's a list of time sources that I've heard of: 0. Set clocks at "factory" I include this for completeness. Perhaps the atomic clocks are set this way. I suspect some clocks in satellites are set this way. 1. The electrical "power grid" This is the familiar 60 Hz (or 50 Hz) AC electric line. One could devise a simple counter of the frequency so that all clocks would always be in step with each other. Unfortunately there are several problems. The first is how to initially synchronize the clocks. Also, there are several (5?) different grids in the 48-state area of the US that are not in sync with each other. Plus, each power-grid master clock is only consistent when averaged over the entire day. When peak demands occur, you aren't getting the full 60 Hz per second that you would expect. I've heard that by about 6pm, the grid is lagging by up to 10 seconds. However that lost time is made up while (most) people sleep so that the alarm clock is correct at 8am. [as an aside: leave work early tomorrow and if anyone asks, just give them the above reason :-)] 2. Phone system Each line used by for phone traffic has some timing-dependencies. Major trunk lines have to synchronize. I don't know the details of how the clocks are set. I vaguely remember something about a master clock for AT'n'T located in Indiana (Illinois?) that serves as the reference clock for the entire network. Anyone know more? Problems with this is that the clock is not reachable by users not in the phone company for free (maybe one could lease a T-1 channel and count bits or watch for the 193'rd etc.). 3. Solar based I've read where early clocks were synchronized to noon by someone who watched an instrument's scale for the instant that the sun be at the highest point in the sky. A tiny filament in the instrument served as the focal point for a slit of sunlight, the instrument could only be tilted north and south so that the seasonal tilt was adjusted for. Problems are that it is tedious and labor-intensive. How to set up the solar spotting tube sounds pretty tricky to me. 4. Universal time This is the collection of atomic clocks (over 100 of 'em) around the world that maintain the time. What's good is that is set up, working, and is correct. Problem is dissemination. Unless you are close to an actual clock, there is some delay. However, it is on the order of milliseconds, not too bad. Expenses are getting a receiver for the signal. In the US, there are several frequencies for WWV. Worldwide, one can use a satellite's broadcast if you are lucky enough to be in its "footprint". The GOES satellite serves North America and some of Pan America. I don't know if there is an equivalent satellite for Europe, Africa or Asia. Using a satellite means you have to pop for a dish antenna. 5. Neutron star A spinning neutron star is very periodic. Some are more than others. One neutron star has been watched for over a decade. During that time, it has shown remarkable consistency -- on par with an atomic clock. I'd have to rummage through my notes to get its designation. Problems: besides buying and installing a radio telescope it is very easy... OK, we got a source of time. Now how do we set the clocks? A convergence algorithm can be structured one of two basic ways. The simplest is in a master/multiple-slaves organization. The harder to implement way is in a distributed fashion where each clock shares its "time" with all other clocks. One has to worry about faults (and Byzantine faults, ie, clocks that are "broken" and give different readings depending on who asks it for the time), and compensating for delay in messages between clocks. But the second way leads to some nice advantages for a data network (deadlock detection is easier, can timestamp things for local and remote use, ...) Another problem is related to how clocks move -- forward. Suppose you are going to reset your clock to a new value of time. What happens if that new value is less than the current reading of a clock? Strange things may happen if you set the clock back! Two ways around this are (1) to "stop" the clock until the clock's reading equals the new time and (2) to run the clock slower for a while. On my old pendulum clock at home, I can shorten or lengthen the pendulum if the clock is running slow or fast, respectively. One can't really change the rate of a digital clock. So, one uses the first method. For an OS that updates its clock by seeing interrupts, if the clock is too far ahead some of the updates can be skipped. If the clock is behind, double up some of the clock updates. Careful consideration needs to be done to see if anything (accounting for one!) breaks. Best to do it when no one is using the machine (but then if updates are scheduled for at night and the machine's clock is 12 hours off, strange things will happen). Berkeley's TEMPO time synchronization protocol changed how the clock is set to be better than one second resolution. [If I could find the paper now, I could tell you more. It was in a Usenix proceedings of a couple years ago.] Bob Devine

1 0

RE: Are these limitations...
by seismo!sun!guy March 21, 1987

March 21, 1987

Would the STRUCTURE of the tm structure have to be changed to accommodate the solar time/lunar calendar or the oriental calendaring systems? It depends on whether you want to use "struct tm" to hold calendar dates in other systems or not. It may be possible (e.g. with a scheme like the one used to represent calculations in "terminfo" strings) to write formatting strings that will convert values from a "struct tm" into dates in various Oriental calendars. Are there weekdays in oriental? We may need to indicate the epoch somewhere (for the reign of the Emporer or whatever). >From what I saw on my trip to Japan, it seems that the only difference between Japanese and Western dates/times is that the year is given as years since the year in which the current emperor took the throne, along with the name of his reign. I.e., "now" is (modulo some transposition of fields) Sunday, 22 Mar, Showa 62 (if I remember correctly, last year was Showa 61), 6:08 AM. (Courtesy of "TZ=Japan /usr/src/bin/date" - thanks, Arthur!) Hebrew used the fall of Adam, Is the past tense deliberate here? What calendar is currently used in Israel? However the Oriental calendar uses assension of the emperor. Or "Oriental calendars use". The Japanese calendar does so; what does the current Chinese calendar do? (I think the Soviets changed to the Gregorian calendar after the revolution; what happened post-1945 in China?) That means things change every so often. Yup. This means you can't guarantee that you can convert times in the future correctly. I'm not sure how the Japanese talk about the year 2087; "Showa 162" would sound a bit presumptuous to me. They may just punt and use the Gregorian calendar here.

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!cbpavo.MIS.OH.ATT.COM!mark March 21, 1987

March 21, 1987

> 2) Provide a general-purpose time value manipulation package > for the benefit of applications that have to deal with > arbitrary dates and times. > > In fact, you may even be able to write the latter package in some > language available on lots of machines (C, Fortran, whatever), and > decouple it from the system entirely. Unfortunately, such a library has to know all the time zone rules, which means it has to redo all the stuff ctime does. It also has to know the local conventions for figuring out what time zone you're in, which means it won't be portable. The bulk of this package would be very similar to ctime.c or ADO's package. I would prefer to see either an upward compatible extension or else a dual interface to the same code. Mark

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!cbpavo.MIS.OH.ATT.COM!mark March 21, 1987

March 21, 1987

Here's a wild idea: If the two high order bits of a time_t are 11, the rest of the bits are taken as a number of days since some early epoch, perhaps 1858 or something in that general ballpark. (1900 isn't quite early enough for our application.) Actually, a quick calculation shows that this allows for nearly 3 million years, so we could easily adopt the year 0 AD as the epoch. The disadvantage to this is that time_t is no longer a simple arithmetic type, although any application that knows it's dealing with timestamps can still assume it is. Only the canned routines like ctime need to know about it. Another disadvantage is that time_t used as a timestamp now only extends to about 2071. By using more than 2 bits as a flag, this could be extended. For example, if the flag were that all 8 high bits are 11111111, it covers 46,000 years, still plenty. It could even be a signed quantity, allowing years from 23,000 BC to 23,000 AD. This only loses 194 days from the end of the range in 2106. Mark

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!sun!guy March 20, 1987

March 20, 1987

Given that some people want a facility in some system library to manipulate dates prior to 1902, why not: 1) Leave the UNIX time manipulation routines alone, and use them only for what they were intended - dealing with time stamps for system events. 2) Provide a general-purpose time value manipulation package for the benefit of applications that have to deal with arbitrary dates and times. In fact, you may even be able to write the latter package in some language available on lots of machines (C, Fortran, whatever), and decouple it from the system entirely.

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!nbires!vianet!devine March 19, 1987

March 19, 1987

Someone wrote: > Yes, but nothing in a UNIX system happened in the 19th century. > Non-UNIX systems lacking "time_t" have done quite well dealing with > times; I don't see any need to use "time_t" for every kind of > timestamp any application could possibly want. Mark replied: ! Sorry, but I disagree. UNIX provides some very nice date/time ! manipulation routines, [...]. I had to reinvent this wheel, and ! I swiped code from ctime like crazy. I wound up choosing ISO time ! (char string) as my standard format. While Unix does not need dates before 1970, I agree it should be more flexible. In order to provide a consistent time format for a network of heterogeneous machines that had time epochs != 1/1/70, I too used the ISO format for dates and times. I didn't have to go as far as Mark did because only network programs (that cared) used the new date/time format; existing programs used OS-dependent calls. Pre-epoch dates were a pain... Bob Devine

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!cbpavo.MIS.OH.ATT.COM!mark March 18, 1987

March 18, 1987

> > Sometimes we care about things that happened in the 19th century > > (birthdates, for example.) > > Yes, but nothing in a UNIX system happened in the 19th century. > Non-UNIX systems lacking "time_t" have done quite well dealing with > times; I don't see any need to use "time_t" for every kind of > timestamp any application could possibly want. Sorry, but I disagree. UNIX provides some very nice date/time manipulation routines, which know about time zones and daylight time, months of the year, leap years, and various other ugly stuff that people don't like to reimplement. An application that has to store a date has a strong incentive to use the existing routines rather than to invent a new format. It would be VERY NICE if the UNIX routines were useful for more than just timestamps on the local system. It is not necessary that time_t be used for this, as long as there is some standard representation that can do it. ctime might be one, ISO time might be one, or struct tm might be one, or it might be something new. I had to reinvent this wheel, and I swiped code from ctime like crazy. I wound up choosing ISO time (char string) as my standard format. My resulting code is highly unportable, because it knows about time_t and two different conventions for time zone, and it has all the daylight rules built into it. Mark

1 0

Re: List of issues
by ado March 18, 1987

March 18, 1987

> > Should time() return an implementation defined time > > representation or should it return elapsed seconds > > since midnight January 1 1970 GMT? > The current POSIX draft already states that it returns the latter; do > we want to change this? No. . .I want to make sure it stays that way. > X3J11 also has "time" and "time_t", although since they're not > defining an OS standard they do not require "time_t" to be an > integral type representing seconds since the epoch. Ideally, I'd like to see both X3J11 and POSIX define time_t as elapsed seconds since midnight January 1 1970 GMT, and see them both define the time function as returning such a value. If this isn't possible, I'd like to see X3J11 define *differently-named* types and functions--tempus_t and tempus, or whatever. My fear is that there are programs out there that "know" what a time_t is that "know" what the "time" function returns, and that will break if things are changed. -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0