Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Re: Timekeeping in ANSI C
Message-ID: <2079@bsu-cs.UUCP>
Date: 11 Feb 88 03:25:37 GMT
References: <461@auvax.UUCP> <28700025@ccvaxa> <7159@brl-smoke.ARPA> <2527@haddock.ISC.COM> <594@acornrc.UUCP>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 32

In article <594@acornrc.UUCP> rbbb@acornrc.UUCP (David Chase) describes a
structure that holds a time value and continues:
>This structure can encode dates from 1900 AD to something like 47000 AD.

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
certain date and time will never come.  Such short-sightedness has
caused problems over and over again, yet we see it again and again.
Just recently we heard about chaos in the DEC-20 world because they had
to extend their time structure and use up some reserved fields that
people had already begun to use for other things.

The right way to do it is as follows:

     typedef struct {
        long hi_time;
        long lo_time;
        time_t *next_val;
     } time_t;

the next_val field will be NULL until 47000 AD, at which time the
routine returning the time value will malloc() space for another struct
to hold the higher 64 bits.  Then, another epoch later, the time_t
structure will become a linked list of three structs, and so on, to the
end of time (or end of free memory).

The only problem I can see with the above typedef is that it won't
compile because of the forward reference.  But at least it will be
valid far longer than anything that compiles that has been proposed so
far.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi