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,start
X-Google-Attributes: gid103376,public
From: gwinn@ma.ultranet.com (Joe Gwinn)
Subject: UNIX/POSIX Time
Date: 1998/10/20
Message-ID: <gwinn-2010982201500001@d106.dial-3.cmb.ma.ultra.net>#1/1
X-Deja-AN: 403394237
Organization: Gwinn Instruments
X-Ultra-Time: 21 Oct 1998 01:55:50 GMT
Newsgroups: comp.lang.ada
X-Complaints-To: abuse@ultra.net
Date: 1998-10-20T00:00:00+00:00
List-Id: <comp.lang.ada>

After being questioned by Keith Thompson about the exact details of POSIX
time, I dug into the references and did some full-precision time
computations.

The UNIX/POSIX time format consists of two *signed* 32-bit integers, one
being the number of seconds since 00:00 UTC 1 January 1970 AD (the
"Epoch", or timescale zero), the other being the number of decimal
nanoseconds into the current second. (Ref: IEEE Std 1003.1-1996 chapter 14)

The above paragraph has been corrected.  We had discussed making the integers 
optionally unsigned, but didn't, for compatibility with existing base.


The full-precision time calculations:

Signed time_t rolls over after 2^31 seconds, which is 24,855.135 days 
from 00:00 UTC 1 Jan 1970 AD, the UNIX Epoch.  

Julian Day  244 0587.500   <-- 00:00 UTC 1 Jan 1970 AD.
             +2 4855.135   <-- 2^31 seconds, in days.

Julian Day  246 5442.635   <-- 03:14 UTC 19 January 2038 AD

This 2038 AD date is what one most often hears as the UNIX rollover.


Un-signed time_t rolls over after 2^32 seconds, which is 49,710.270 days 
from 00:00 UTC 1 Jan 1970 AD, the UNIX Epoch.  

Julian Day  244 0587.500   <-- 00:00 UTC 1 Jan 1970 AD.
             +4 9710.270   <-- 2^32 seconds, in days.

Julian Day  249 0297.770   <-- 06:29 UTC 7 February 2106 AD


The 2100 AD figure comes from a rougher calculation, sufficient for most
purposes, as I plan to be dead, buried, and forgotten by then.

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