On 2005-03-06, Robert Elz wrote:
Date: Thu, 3 Mar 2005 14:49:27 -0500 From: "Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> Message-ID: <75DDD376F2B6B546B722398AC161106C74038F@nihexchange2.nih.gov>
| As long as we're making changes, it's best to do as much as possible | (to avoid the need for further change down the road).
No, please try and avoid typical 2nd system effects, with the grand temptation to add everything that anything can imagine might possibly be of some interest to someone, somewhere, sometime. Change only what absolutely needs changing because of demonstrated need now. What exists is currently pretty good, the 64 bit issue is certainly going to bite sometime, so that one ought be fixed, there's nothing else (or very little) so seriously wrong with that exists now that makes it important to change, I suspect.
I support this argument, with a couple of small but important exceptions (see below).
Back to 1970, forward to today + 100 years (maybe 200, no more).
No, this is not enough for common uses of today's systems. We deal with dates in commerce and academia all the time to get our work done. One kind of date that we have to deal with regularly is birth dates. Everybody here was probably born before 1970. And we often have to deal with parents' birth dates. That means going back to 1900 at the very least, but probably to 1800 to be safe. Equally, we deal with contracts that extend into the future, not forever, but for periods sometimes in excess of 100 years, so we need to go 200 years forward as well. With this small window of 400 years, we avoid most of the hard stuff while also providing a date thing that is useful to common software, instead of continuing to force every database vendor in the world to invent yet another date mechanism. Greg