Re: History of IEEE P1003.1 POSIX time

From: <ut1-mail_at_ASTHE.COM>
Date: Thu, 30 Jan 2003 23:32:19 GMT

> 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/\
Received on Thu Jan 30 2003 - 15:32:43 PST