The End of the UNIX Epoch

oulevon · 11-19-2003, 12:34 PM

Does anyone know the exact date of the end of the UNIX Epoch if a 32 bit unsigned int is used to keep track of the seconds since January 1st 1970? I understand that a 32 bit unsigned int can hold 4,294,967,295 seconds. And since there are 3600 seconds in an hour and 86,400 seconds in a day, and 365.25 days in a year, then I get that the epoch will end in 49,710.2696 days which is roughly 136.099 years. But does anyone have the exact date. I want to make sure my calculations are right. Most of the stuff I found on the web concerned a 32 bit signed integer and as such that would end in 2038. Any help would be appreciated. Thanks.

jim mcnamara · 11-19-2003, 01:38 PM

22:14:07 on January 18, 2038

EyesOnly · 11-19-2003, 01:50 PM

I just stumbled in your thread, and now I am somewhat curious,
what is a Epoch? what will end at 22:14:07 on January 18, 2038?

oulevon · 11-19-2003, 02:14 PM

Jim, thanks for your help, but that figure is for a signed 32 bit integer. I need the date for an unsigned 32 bit integer.

EyesOnly,
The UNIX Epoch is the beginning of time in UNIX which started at January 1st 1970 at 00:00:00. The Date is measured upon the number of seconds ticked off since this time. If you're more interested in the general form of an "Epoch" this is what I got from www.dict.org:

4 definitions found

From Webster's Revised Unabridged Dictionary (1913) :

Epoch \Ep"och\ (?; 277), n. [LL. epocha, Gr. ? check, stop, an
epoch of a star, an historical epoch, fr. ? to hold on,
check; 'epi` upon + ? to have, hold; akin to Skr. sah to
overpower, Goth. sigis victory, AS. sigor, sige, G. sieg: cf.
F. ['e]poque. See Scheme.]
1. A fixed point of time, established in history by the
occurrence of some grand or remarkable event; a point of
time marked by an event of great subsequent influence; as,
the epoch of the creation; the birth of Christ was the
epoch which gave rise to the Christian era.

In divers ages, . . . divers epochs of time were
used. --Usher.

Great epochs and crises in the kingdom of God.
--Trench.

The acquittal of the bishops was not the only event
which makes the 30th of June, 1688, a great epoch in
history. --Macaulay.

Note: Epochs mark the beginning of new historical periods,
and dates are often numbered from them.

2. A period of time, longer or shorter, remarkable for events
of great subsequent influence; a memorable period; as, the
epoch of maritime discovery, or of the Reformation. ``So
vast an epoch of time.'' --F. Harrison.

The influence of Chaucer continued to live even
during the dreary interval which separates from one
another two important epochs of our literary
history. --A. W. Ward.

3. (Geol.) A division of time characterized by the prevalence
of similar conditions of the earth; commonly a minor
division or part of a period.

The long geological epoch which stored up the vast
coal measures. --J. C.
Shairp.

4. (Astron.)
(a) The date at which a planet or comet has a longitude or
position.
(b) An arbitrary fixed date, for which the elements used
in computing the place of a planet, or other heavenly
body, at any other date, are given; as, the epoch of
Mars; lunar elements for the epoch March 1st, 1860.

Syn: Era; time; date; period; age.

Usage: Epoch, Era. We speak of the era of the
Reformation, when we think of it as a period, during
which a new order of things prevailed; so also, the
era of good feeling, etc. Had we been thinking of the
time as marked by certain great events, or as a period
in which great results were effected, we should have
called the times when these events happened epochs,
and the whole period an epoch.

The capture of Constantinople is an epoch in the
history of Mahometanism; but the flight of
Mahomet is its era. --C. J. Smith.

From WordNet (r) 2.0 :

epoch
n 1: a period marked by distinctive character or reckoned from a
fixed point or event [syn: era]
2: (astronomy) the precise date that is the point of reference
for which information (as coordinates of a celestial body)
is referred [syn: date of reference]
3: a unit of geological time

From Jargon File (4.3.0, 30 APR 2001) :

epoch n. [Unix: prob. from astronomical timekeeping] The time and date
corresponding to 0 in an operating system's clock and timestamp values.
Under most Unix versions the epoch is 00:00:00 GMT, January 1, 1970;
under VMS, it's 00:00:00 of November 17, 1858 (base date of the U.S.
Naval Observatory's ephemerides); on a Macintosh, it's the midnight
beginning January 1 1904. System time is measured in seconds or ticks
past the epoch. Weird problems may ensue when the clock wraps around
(see wrap around), which is not necessarily a rare event; on systems
counting 10 ticks per second, a signed 32-bit count of ticks is good
only for 6.8 years. The 1-tick-per-second clock of Unix is good only
until January 18, 2038, assuming at least some software continues to
consider it signed and that word lengths don't increase by then. See
also wall time. Microsoft Windows, on the other hand, has an epoch
problem every 49.7 days - but this is seldom noticed as Windows is
almost incapable of staying up continuously for that long.

From The Free On-line Dictionary of Computing (27 SEP 03) :

epoch

1. [Unix: probably from astronomical timekeeping] The time and
date corresponding to 0 in an operating system's clock and
timestamp values. Under most Unix versions the epoch is
00:00:00 GMT, January 1, 1970; under VMS, it's 00:00:00 of
November 17, 1858 (base date of the US Naval Observatory's
ephemerides); on a Macintosh, it's the midnight beginning
January 1 1904. System time is measured in seconds or ticks
past the epoch. Weird problems may ensue when the clock wraps
around (see wrap around), which is not necessarily a rare
event; on systems counting 10 ticks per second, a signed
32-bit count of ticks is good only for 6.8 years. The
1-tick-per-second clock of Unix is good only until January 18,
2038, assuming at least some software continues to consider it
signed and that word lengths don't increase by then. See also
wall time.

2. (Epoch) A version of GNU Emacs for the X Window System
from NCSA.

[{Jargon File]

lambada · 11-19-2003, 03:50 PM

but... won't that date be a new Y2K??? :S

rshaw · 11-19-2003, 04:49 PM

only on the few remaining 32 bit museum pieces.

Hko · 11-19-2003, 05:52 PM

Quote:

but... won't that date be a new Y2K??? :S

Yes, I guess so.
But there are still about 35 years left to fix it....
Hope Linux supports 64-bit by then... ;-)

EyesOnly · 11-20-2003, 09:01 AM

Thanks for the expanation.
So what will happen if this Epoch ends?
If the beginning of the Epoch is the beginning of times, will the end of it means the end of times?

There is one thing i don't really get yet..

Quote:

Microsoft Windows, on the other hand, has an epoch problem every 49.7 days - but this is seldom noticed as Windows is almost incapable of staying up continuously for that long.

So epoch problems aren't noticed on Windows system, because the don't run that long, but that should mean the epoch starts again every time the system boots, right?
If so, i don't see a problem (unix has a epoch of 68 years, i dont think anyone can get an uptime that long..

).
Or does the unix epoch work diffrent?

jim mcnamara · 11-20-2003, 09:34 AM

No. He's talking about GetTickCount() which returns the number of ms the system has been up. It returns an unsigned long, which rolls over to zero after about 60 days. It's not the same thing as what oulevon is talking about.

Windows uses a quadword (unsigned long) for keeping track of the date/time in seconds. The GetTickCount() thing is strictly a separate counter, mostly used for performance analysis, loop timing, etc.

Unix uses a quadword as well. It keeps track of the number of seconds since 1970. The problem is, in spite of oulevons' good intentions, time(), gmtime(), asctime(), and everybody else in the time.h family is gonna barf (more correctly - stop giving correct results) in January 2038. As an example, the unix command "date", as well as file dates/times will start having problems at that point.

Play with this code - change the value for end_of_time and you'll see that things start doing interesting stuff when endof_of_time is set larger than
0x8fffffff.

Code:

#include <time.h>
#include <stdio.h>
int main(int argc, char *argv[]){
        struct tm *tmptr;
        char t[128];
        time_t end_of_time=0xfffffffe; /* should be the year 2100+ or so */
        tmptr=gmtime(&end_of_time);
        printf("%s\n",asctime(tmptr));
        return 0;

oulevon · 11-20-2003, 03:08 PM

Quote:

Originally posted by jim mcnamara
The problem is, in spite of oulevons' good intentions, time(), gmtime(), asctime(), and everybody else in the time.h family is gonna barf (more correctly - stop giving correct results) in January 2038. As an example, the unix command "date", as well as file dates/times will start having problems at that point.

I'm not sure what you mean by my "good intentions". I was trying to answer the following question in my operating systems book:

"28. Many versions of UNIX use an unsigned 32-bit integer to keep track of the time as the number of seconds since the origin of time. When will these systems wrap around (year and month)? Do you expect this to actually happen?"

- Page 376 Chapter 5
Modern Operating Systems 2nd Edition
Andrew S. Tanenbaum

The only reason I asked the question on here was because I was afraid I was calculating the Leap year incorrectly. I wasn't trying to assert that the end of time would be in 2038, because the question didn't concern a signed 32-bit integer, but rather an unsigned 32-bit integer.

jinksys · 11-22-2003, 02:42 AM

maybe this will help, taken from WIKIPEDIA's Unix Epoch topic....
Effects of the 2038 rollover

Programs which must handle times beyond the rollover data will need to be changed to accommodate a shift from 32-bit to 64-bit representation, not unlike the Year 2000 problem. Adapting existing programs may be as easy as re-compiling them with header files that declare time_t as a 64-bit integer, but other programs make deep assumptions as to the nature of time_t. Also, the source code to some software packages may have been lost by then, in which case programmers might have to reverse engineer the software to change its date behavior. In fact, some claim that the expiration of the Unix epoch timeframe may cause more damage than was predicted for the Y2K bug.