Timekeeping in ANSI C

[David Keppel]

In article <1152 at ucsfcca.ucsf.edu> roland at rtsg.lbl.gov (Roland McGrath) writes:
>["Timekeeping in ANSI C"] - dhesi at bsu-cs.UUCP (Rahul Dhesi):
>} Sooner than you can say "UNIX is a Trademark of ...", 47000 AD will be
>} here.  The greatest mistake a designer can make is to assume that a
>
>If we're still using Unix (or POSIX, or GNU) in AD 47000,
>or even 2038, I will do repeated belly-flips in my grave (or
>perhaps in my armchair in the case of the latter).

Just a comment.

Mutual of Omaha Insurance does most of their munching on a *huge* IBM
mainframe that is recent technology -- but the processing is all batch
because

(a) there is a lower overhead for batch processing (they are CPU bound)
(b) that was what was available when they made their software investment
(c) it still does their job about as good as anything (see (a))

I can't say which is a bigger factor, but they're all relevant.  The
greater principle here has been espoused by lots of people, and I heard
it most recently from Richard Stallman, something along the lines of
(this is not a quote)  "Don't make any assumptions about how big the
input is going to be".  If the machine will let us allocate 1Mb and the
user asks us to allocate 1Mb, then by all means do so.  But don't
compile in any limits, in 5 years somebody will want 1Tb (terabyte) and
have a machine that can do it.

Consider: if the "timeval" structure is sufficiently general than it need
not be used just for system time, but can be used by applications to
hold interesting things like the birthdate of Charles Babbage and the
applications don't have to invent their own storage format and (possibly
buggy, probably incompatable) manipulation/printing routines.

As far as I can tell, this doesn't have anything to do with comp.lang.c
anymore.

 ;-D on ("$128,000 Pyaramid" started out as "The $64 Question"--on radio) Pardo