Path: utzoo!utstat!helios.physics.utoronto.ca!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!uunet!ladcgw!frank
From: frank@ladc.bull.com (Frank Mayhar)
Newsgroups: news.software.b
Subject: Re: Our friend, the GMT date.
Message-ID: <1989Dec8.015911.7810@ladc.bull.com>
Date: 8 Dec 89 01:59:11 GMT
References: <4364@helios.ee.lbl.gov> <14810@well.UUCP> <1989Dec3.210413.27043@psuvax1.cs.psu.edu> <56239@looking.on.ca>
Reply-To: frank@ladcgw.ladc.bull.com (Frank Mayhar)
Organization: Bull HN Information Systems Inc. Los Angeles Development Center
Lines: 20

In article <56239@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes:
>Almost makes me wonder if we/they shouldn't have started with a machine
>only date field, integer seconds since some epoch.  (Could use the Unix
>epoch, or even the USENET epoch, I guess.)

I dislike this idea intensely.  The problem you run into with this scheme is,
how do you represent it?  In my experience, it has been as a single machine
word.  This has all sort of nasty side effects, as has been noted recently
in other groups; side effects such as the software breaking when the sign bit
turns on (my organization had to solve this for our OS two years ago), or
when the count exceeds the size of the machine word.  Certainly good design
should take care of this, but how many software systems nowadays are designed
that well?  Answer: very few, if any.  And no matter how well you design it,
SOMEBODY will exceed the design limits.  So the best idea is to use some
scheme that isn't limited, or at least has no effective limits.  (How many
people are going to be using Unix in the year 21561?  Not many, is my guess.)
-- 
Frank Mayhar  frank@ladc.bull.com (..!{uunet,hacgate,rdahp}!ladcgw!frank)
              Bull HN Information Systems Inc.  Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045    Phone:  (213) 216-6241