[ale] End of Time, *nix Time

[jc.lightner at comcast.net]

This made me think of my annoyance at logs for some apps that did epoch timestamps.  More than once I wrote a script to calculate human readable time as it displayed lines from such logs.  I’m sure there are some who can eyeball epoch and convert it mentally to star date and other clock/calendar systems but I wasn’t one of them.  

Which also made me think of the fact that some logs are in UTC rather than local time zone time.  At least I could do that conversion in my head.  

Back when we tested for Y2K bugs many of us who were UNIX admins also tested for future dates against the 32 bit limit and other factors.   I often thought it odd that most UNIX platforms already did 64 bit whereas many Linux distros didn’t even if they were on a 64 bit processor.   

 

From: Ale <ale-bounces at ale.org> On Behalf Of Ron via Ale
Sent: Saturday, April 25, 2026 1:29 PM
To: ale at ale.org
Cc: Ron <ron at bclug.ca>
Subject: Re: [ale] End of Time, *nix Time

 

Bob Toxen via Ale wrote on 2026-04-24 19:43:

  # Download this program:
  wget http://verysecurelinux.com/xtime.c
  # Compile:
  make xtime
  # Run:
  ./xtime -q

I downloaded an compiled this.

Lots of warnings when running `make`, but it compiled.

What am I to make of the output? I can make no sense of it.

 

$ ./xtime -q
Copyright (c) Bob Toxen 2026.  All rights reserved.

This program will analyze your *nix for the well-known bug if the
seconds since 01/01/1970 exceeds a signed 32 bit (4-byte) integer.
If it outputs abnormal output for years beyond 2038 then your computer
will fail at that time, about 12 years from now.

Many *nix systems were fixed decades ago so that this variable became
an unsigned 32-bit int, which can keep time until 2106.
More recently most systems went to a signed 64-bit int.

Note that most Unix and Linux distributions corrected the time
problem by approximately 2014 to work until 2106 (using an unsigned
32-bit number) or well beyond if using a 64-bit number but maybe the code
will fail before the largest 64-bit signed (292,271,022,989 years)
or unsigned number is exceeded.


If it is not fixed in your version, well, good luck.

sizeof char=1, sizeof short=2, sizeof int=4, sizeof long=8, sizeof long long=8, sizeof time_t=8

Current years and seconds since the epoch: 56 1777137911
  seconds/year:31536000, seconds/year including leap year:31557600, delta seconds:21600, delta hours:6

Biggest   signed 4-byte long: years inc=            0, years in the future=           11, Mon Jan 18 19:14:07 2038
Biggest unsigned 4-byte long: years inc=            0, years in the future=           79, Sat Feb  6 22:28:15 2106

Time: years inc=            1, years in the future=   2147437525, Wed Jun 12 15:25:11 2147483647

Welcome to the Restaurant at the end of the universe.  Hello, your Majesty.

Biggest   signed 8-byte long: years inc=            0, years in the future= 292271022988,
ERROR: Invalid seconds since Epoch in localtime
Error code: Value too large for defined data type

Biggest unsigned 8-byte long: years inc=            0, years in the future=          -56, Wed Dec 31 15:59:59 1969

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20260425/c5290b7e/attachment.htm>