> Thanks for giving us this history. You are most welcome.
The POSIX time dance was an interesting lesson is damage mitigation vs. desire to do something better than existing common practice. During the process some of the active POSIX P1003.1 members ended up learning a lot more than they expected to learn about time. :-) I once gave a 45-minute BOF/evening talk on time scales and the history of time in an effort to convince some people that time was not a simple topic. Of course the story of now Coordinated Universal Time came to be UTC is another interesting lesson in politics. :-) > So the 32-bitness of time_t was at that time wired into Posix? Nearly all implementations had time_t an int32_t. It was not required. There have been one implementation (Cray?) that used int64_t. Some implementations tried to get away with u_int32_t. All that you could portably depend on was 31 unsigned bits. Even today many implementations use a 'long int' which is a 32 bit signed value on many architectures. > Quite so, although if the relationship is vague enough (i.e. the synodic > month vs. the civil month), then we can sometimes force clean behavior. Yes, we agree. Leap years are one such example of forcing a cleaner behavior. IMHO, leap seconds are another. =-= Can anyone hazard a guess as what the status of leap seconds and time scales will be in the next few years? Do people think that the relevant standards bodies will make a change? Is so, what do you think they might do? Does any one particular proposal have "an edge" where it matters - decision wise? chongo () /\oo/\