Pun intended.

"68 years ought to be enough for anybody"

"68 years ought to be enough for anybody"

In which case I'm definitely on borrowed time.

Yes, for some of us, the clock is ticking ever so closer to the day that the ticker gives up for ever.

"Yes, for some of us, the clock is ticking ever so closer to the day that the ticker gives up for ever."

Possibly for all of us (except thise who are Time Lords) time passing as it does.

There was a heads up at the 34 year mark, when a bunch of users of various equipment discovered their NTP implementations were using signed 32 but integers to represent dates

Among other things it disabled most of the Chinese Internet for about 12 hours

Isn't Epoch 1970?

It's a signed number. The overflow wraps around to a negative value.

D'Oh - of course it is... that's about December 1901... that's probably close enough to 1900 to count, it's just too easy to assume that it's a Y2K typo...

If Unix time is stored in a signed 64-bit integer, the rollover will occur approximately 292.277 billion years from January 1, 1970.

This means the new rollover time is Sunday, December 4, 292,277,026,596 AD at 15:30:08 UTC.

What are we supposed to do THEN?

Declare that the year of Linux on the Desktop has finally arrived?

Too soon...

Well, we now know the maximum up-time hard limit for a Linux install.

By then there will no longer be kernel support for anything older than 42000 core 4096-bit processors, but that will be just to keep a few grey-beards happy.

Well, for one, by then my grudge against you for stealing MY planned joke post, might abate!

" This means the new rollover time is Sunday, December 4, 292,277,026,596 AD at 15:30:08 UTC.

What are we supposed to do THEN? "

Advent Sunday. Go to church ?

Well, just having looked at Wiki's deep time pages, there's a chance that either the "false vacuum collapse" occurs or the Big Rip happens and the expansion of the universe ends baryonic matter.

But do I see anybody planning for *that* eventuality?! Of course not! Short-term thinking abounds!

The sun will have long since burnt out, so 64 bit unix time will be the least of our worries.

"The stars are receding...! Ohhh, the vast emptiness!" "...Yeah, yeah, I can take a hint."

And then 128-bit time be like "Bye, last proton!"

We will let an AI make all the changes, it will f***

up everything, and we will never have working computers ever again.

We can just start using 256-bit integers. Should be long enough to survive the heat-death of the entire universe.

Funnily enough, things will break earlier than that. The struct that converts the Unix epoch to a more understandable day month year format has the year itself as a 32-bit integer so by the year 2million something or 4 million something that int will overflow and blow up the time conversion function.

Will they make it before the year 8907?

Powershell:

[datetime]::FromFileTime(([int64]::MaxValue)/4)

Montag, 5. Dezember 8907 19:42:01

+- a few nanoseconds.

I dont envy them having to make the change over so many packages. Best of luck

Well the actual change would just be in time.h, wouldn't it?

Okay, admittedly you'd have to recompile a sh*t-ton of code ... "Debian's maintainers found the relevant variable, time_t, 'all over the place,' spread across a total of 6,429 packages."

That assumes that nobody is doing any maths using 'long' instead of time_t, nor are they using it in any structure/ABI that is fixed. Obvious example is reading date from a file system, I think ext4 uses 64-bit time stamps but ext3 uses 32-bit so there is some conversion needed there and you can't just compile the file system driver without checking the devilish details.

ext3 uses 32-bit so there is some conversion needed there and you can't just compile the file system driver without checking the devilish details.

As it's impossible that any Unix file was actually created before 1st January 1970(*), 32 bit filesystem times can always be interpreted as unsigned, giving an extra 68 years to deprecate the file system format. I'm not saying it's a no brainer, but it shouldn't be impossible.

(*) Unless someone's been playing silly buggers, which is of course guaranteed to have been done somewhere. They can sort themselves out as punishment.

"That assumes that nobody is doing any maths using 'long' instead of time_t, "

All the code littered with t ≠ (time_t)(-1) I am surprised that there isn't more brokenness 0n 64 bit platforms.

Just t ≠ -1 or t ≠ -1L for starters.

Return valid results and error indications in a single value perhaps not greatest design decision.

@LionelB

"Well the actual change would just be in time.h, wouldn't it?

Okay, admittedly you'd have to recompile a sh*t-ton of code ... "Debian's maintainers found the relevant variable, time_t, 'all over the place,' spread across a total of 6,429 packages.""

Possibly but not guaranteed. I might be wrong but there is a length difference between 32bit and 64bit and if it is being loaded into a variable of an assumed shorter size it could cause a problem (do correct me if I am wrong I dont spend a lot of time in the lower languages). How much can and will go wrong I do not know, I did find this description of the issue for Gentoo-

https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/

As I said I dont envy Debian guys and wish the best of luck

No. You may well have zillions of ancient tarballs and backups that were written in the days when time_t was a signed 32-bit integer.

"Well the actual change would just be in time.h, wouldn't it?"

Nope.

Other OS components may assume/rely on time being 32bit - for example the UTMP/WTMP files used to track Unix/Linux logins/logouts (used by "w", "who", "last" etc commands) *rely* on the timestamp being 32bit as the file format is defined as so by the POSIX standard and the UTMP/WTMP files are binary files and so if 64bit values were to used instead then such files would no longer be standards compliant and they also wouldn't be backwards compatible.

One solution to the above is an alternative (i.e. new) way of tracking logins/logouts which some Linux software is starting to support - wtmpdb.

"the file format is defined as so by the POSIX standard"

No it isn't. POSIX only defines the API used to access the utmp file, not the file format. There is no requirement that the file is just a binary containing the utmpx structures used by the API. And anyway the structure has the time as a struct timeval which has a time_t member for the seconds, and POSIX (as of the 2024 revision) requires time_t to be at least 64 bits. So on a system where the file does contain utmpx structures, the file would need to have at least 64-bit for the seconds in order to conform.

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/utmpx.h.html

"No it isn't. POSIX only defines the API used to access the utmp file, not the file format."

Sorry, you are correct.

The point is that in order to use 64bit time values would mean changing the "standardised" (by existing software) on-disk format of UTMP/WTMP files and this would require changing a lot of software that either writes or reads (or both) these files and also would introduce compatibility issues between "old" format and "new" format files unless software was modified to detect both formats of file and act accordingly.

Some background info here: https://github.com/thkukuk/utmpx/blob/main/Y2038.md

No, Posix doesn't mandate 32 bit time fields in utmp.

So, as with everything else, if all those programs were written properly, just altering time_t and compiling would work (Of course, it would break with historical data)

The main problems are:

1) Providing backwards compatibility (even if you don't care about old programs, there is also old data to cope with)

2) Auditing that every code does indeed use time_t appropriately and not make 32 bit assumptions. However, I suspect this auditing would have been done already when the OS started to support 64 bit architecture.

"having to make"

Already a done deal as far as I can see,. Trixie is Debian Next and also the basis for Devuan Excalibur which I've been running as test for several weeks and is currently my daily driver because the no 1 laptop has suffered a bit of a knock & is in for repair.

Not sure about LMDE.

Just another reason why I keep coming back to Debian after trying anything else.

Have a few of the icon folks.

Yep. The developers learned from Y2K, Corporate applications will be in a last minute panic, though, because it's not "profitable" to fix ahead of time. They'd rather pay through the nose at the last minute after the current management has left on their golden parachutes.

The Accounts dept. have determined that the finalised budget can't be ready before Friday, December 2, 292,277,026,596 AD.

Please don't remind me about accounts departments and Y2K

I know, I'm being pedantic, but why use "The Y2K38 bug"?

For a start, it's not a bug per se; it's how it was programmed.

Secondly, why use five characters, as in Y2K38? What's wrong with just 2038, or if you must use five characters, what's wrong with Y2038?

IT people are well aware of this potential issue and are working on it and have been working on it for years, possibly decades. There's no need to be dramatic and alert the general public, therefore no snazzy "punchline" is required.

And talking of which, yes I am of "a certain age" and was involved in mitigating things the last time and well remember the scare stories of aeroplanes falling out the sky, banks going bust and you losing all your money, etc. Where are the scare stories for this "potential year 2038 32-bit time-related potential issue with Unix systems" thingie? If you're going to be dramatic with the headlines, at least be dramatic with the copy, too. (And I'm not singling out El Reg ; other publications are as equally guilty.)

> ... or if you must use five characters, what's wrong with Y2038?

Or, for brevity, just Y38.

It's even worse than that. The K as separator has presumably been borrowed from electronics usage, but engineers are expected to know about place values.

So a 2K38 resistor is not 2038 ohms, but 2380 ohms. Any numerate person would have called it the Y2K038 problem, not saving any digits at all.

> For a start, it's not a bug per se; it's how it was programmed.

You could say the same about the Y2K bug.

The Y2K "deniers" will be here soon to explain why the problem does not exist . . .

Well?

It's only a problem when you measure time from one of the eight corners of the Earth. On the other seven corners of the cube, time proceeds differently, so as we measure time in binary (one corner), it's really advancing in octal, so we have thirty-two times as long to resolve the problem as these so-called "programmers" believe.

In other words, this is a non-story, and everyone can stop panicking. You're welcome.

Truly, the old ones are the best...

Rest in peace, Gene Ray - truly the wisest man on Earth. Better than certain great men these days, at any rate.

" The Y2K "deniers" will be here soon to explain why the problem does not exist . . .Well? "

The planet might be fortunate to reach 2028 before a new dark age falls on us.

We will then be back to counting new moons; Ides, Kalends and Nones. :)

TBH, when we checked all our kit/software in the late 90s, nothing needed changing to be Y2K-ready. But then we weren't running any COBOL stuff. Still aren't, actually.

It wasn't just COBOL programs - there was plenty of C derived stuff that had issues. A lot of it was just display oriented (although, you never know who is doing what with the display), other parts would definitely have broken without a patch when we looked.

I saw many C and JavaScript programs that would have had the display go from 1999 to 19100. We all know what they did wrong there!