Path: utzoo!mnetor!uunet!husc6!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.lang.c
Subject: Re: Timekeeping in ANSI C
Message-ID: <2716@mmintl.UUCP>
Date: 16 Feb 88 23:35:22 GMT
References: <461@auvax.UUCP> <28700025@ccvaxa> <7159@brl-smoke.ARPA> <2527@haddock.ISC.COM> <594@acornrc.UUCP> <2079@bsu-cs.UUCP>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT.
Lines: 26

In article <2079@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>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.

This is a joke, right?

The correct rule is that any built-in limitations should be ridiculously
large.  2050, for example, is not ridiculously large; even 2500 isn't
really.  But 47000 *is* ridiculously large, and thus this scheme meets the
criterion.

I *do* have a problem with it, however: it doesn't go back far enough.
Sure, nobody is going to need to represent current times before 1900 on
their computer, but a good system for representing dates should be able to
deal with history, as well.  To be on the safe side, I would go back to
10000 BC; this still gets us to 37000 AD.

(Of course, now you get into the issue of the Julian calendar.)
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108