🚀 go-pugleaf

Brian Hampson writes
>Curt Sampson (curt@cynic.portal.ca) wrote:
>
>: >UNIX is scheduled to run out of "time", as it stands in 2038.  However, 
>: >that gives people a bit of time to work around it.  The C programming 
>: >language neatly gets around an integer time problem by saying that time_t 
>: >is a constantly increasing value...It is NOT guaranteed to be an int or a 
>: >long int...just ever-growing.  
>
>: There's not much to `getting around it'; UNIX itself does most of
>: its date work in type time_t, so just increasing it from 32 to 64
>: bits will do the trick quite nicely for some time to come. It can't
>: hurt any more than moving some of the inode stuff to 64 bits,
>: really....
>
>True, although on our UNIX system there is a 
>
>#define time_t int
>
>or some such...they'll have to do something about that <grin>, but for 
>the most part...shouldn't be a problem, unless you have people writing 2 
>digit dates still.  (Are there people that ACTUALLY still do this????)
>
>Cheers,
>
>B.

     time_t time(time_t *tloc);

     Time returns the value of time in seconds since 00:00:00
     GMT, January 1, 1970.

On our system, time_t is:

typedef long time_t;

sizeof(long) on our system is 4 octets (32 bits).

That gives storage for about 136 years beyond January 1, 1970.
I won't lose any sleep over it.

--
Brad Head <brad@instep.bc.ca>				__   __o
Software Developer, InStep Mobile Communications Inc.	___ `\<,
Atomic Racing Club, Vancouver, BC, Canada		--  O/ O