UNIX/POSIX Time

UNIX/POSIX Time

[Joe Gwinn]

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

Re: UNIX/POSIX Time

[Dale Stanbrough]

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

Re: UNIX/POSIX Time

[Markus Kuhn]

dale@cs.rmit.edu.au (Dale Stanbrough) writes:
|> 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).

C's time.h is broken in a great number of ways (there have already been
many complaints about this during the ISO C89 standardization process), and
there are currently several proposals around to replace it completely in
ISO C 9X. Mine is on

  http://www.cl.cam.ac.uk/~mgk25/c-time/

including references to other proposals.

Have a look at it (especially the rationale) if you are interested in
problems there are and how they could be fixed nicely. I think my proposal
contains numerous ideas that should also be of interest for the time API
designers of other languages. Ada.Calendar is certainly better than time.h,
but far from perfect and lacks for instance support for UTC leap seconds
and local time zones.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>