[ale] End of Time, *nix Time
Bob Toxen
transam at verysecurelinux.com
Tue Apr 28 12:46:09 EDT 2026
Jon,
I'm so sorry to hear about your health issues. I am flattered that
you took the time to reply.
Best hospitals are in NYC and worth the travel. You (and anyone else)
is welcome to contact me for details. It's where I had my back fixed
after Atlanta docs surgery wasn't successful.
Bob
On Tue, Apr 28, 2026 at 08:25:44AM -0400, Jon "maddog" Hall wrote:
> Quite frankly at the age of 75, diabetic, three heart attacks and only 26%
> of my heart capacity left I do not think I have to worry about this.
>
> But it was fun reading about it anyway.????
>
> On Sat, Apr 25, 2026, 23:54 Bob Toxen via Ale <ale at ale.org> wrote:
>
> > I've just uploaded the new and improved code to my web site so please
> > download again and email just me (transam at VerySecureLinux.com) if you
> > get any more compiler warnings or strange results to be addressed.
> >
> > This new version improves the messages to be less cryptinc but the
> > program does assume you know something about how time is handled in
> > *nix. The short answer is that if you have the old signed 32-bit
> > time_t type then the largest year you will see will be 2038 in
> > output of the form "Day-of-week Month Day ##:##:## Year".
> >
> > If you get a reference from Hitchhiker's Guide to the Galaxy then
> > you have the new 64-bit time_t type and you should be good for the
> > next two billion years.
> >
> > Please send me comments to address.
> >
> > Bob
> >
> > On Sat, Apr 25, 2026 at 02:38:03PM -0400, Jeff Lightner via Ale wrote:
> > > 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
> > >
> > >
> > >
> >
> > > _______________________________________________
> > > Ale mailing list
> > > Ale at ale.org
> > > https://mail.ale.org/mailman/listinfo/ale
> > > See JOBS, ANNOUNCE and SCHOOLS lists at
> > > http://mail.ale.org/mailman/listinfo
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > https://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> >
More information about the Ale
mailing list