From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e36545482e8e19b4
X-Google-Attributes: gid103376,public
From: dale@cs.rmit.edu.au (Dale Stanbrough)
Subject: Re: UNIX/POSIX Time
Date: 1998/10/21
Message-ID: <dale-2110981239580001@dale.ppp.cs.rmit.edu.au>#1/1
X-Deja-AN: 403406111
References: <gwinn-2010982201500001@d106.dial-3.cmb.ma.ultra.net>
X-Complaints-To: abuse@cs.rmit.edu.au
X-Trace: emu.cs.rmit.edu.au 908937489 19135 131.170.27.23 (21 Oct 1998
 02:38:09 GMT)
Organization: RMIT
NNTP-Posting-Date: 21 Oct 1998 02:38:09 GMT
Newsgroups: comp.lang.ada
Date: 1998-10-21T02:38:09+00:00
List-Id: <comp.lang.ada>

Joe Gwinn wrote:

" I would not expect rollover in 2038 to be a problem, as time_t will become
  a 64-bit signed number by then, deferring the issue for 2.9e11 years, or
  so.
  
  Joe Gwinn"

Then you have more faith in the ability of people to learn from the
lessons taught by the year 2000 problem than I do.
I have *infinite* faith that the lessons will be "dead, buried, and
forgotten by then" by the vast majority of IT sites.

For those of use who are around then, we'll no doubt be annoying relatives
and friends with numerous "i tried to tell you but no one would listen to
me".

My guess? It will be too costly to replace 32 bit time_t, so a 64 bit
time_t (time_t_64?) will be introduced along side it, and lots of code
will continue to use time_t (32).

Dale