#Y2038 isn’t just a 32-bit issue! On bi-arch systems, the Year 2038 bug still lurks in places like utmp, wtmp, btmp, and lastlog. Watch how #openSUSE tackles it. https://youtu.be/4biGLiBBIds?si=zpy4aCswrIQGMuBi
Recent searches
Search options
Administered by:
#y2038
0 posts0 participants0 posts today
Zum 85. Geburtstag: "Chuck Norris kann das Jahr 2038 Problem lösen"
Fedora 43 will provide improved user experience!
#Fedora #FedoraLinux #Linux #TechNews #TechUpdates #Computers #Fedora43 #Year2038 #Y2038 #Y2038Problem #Year2038Problem
https://officialaptivi.wordpress.com/2025/03/10/fedora-43-and-rpm-6-0-jpeg-xl-wallpapers-and-more/
Aptivi · Fedora 43 and RPM 6.0, JPEG-XL wallpapers, and more…
More from 
Aptivi
www.phoronix.comFreeBSD 13.5 Overcomes UFS Y2038 Problem To Push It Out To Year 2106
Noch 13 Jahre bis zur Epochalypse! Wenn das nur nicht Unglück bringt...
Internet Hoax oder digitales Armageddon. Am 19. Januar 2038 wissen wir definitiv mehr.
Wir haben zum Thema eine neue Website https://www.y2k38.ch aufgeschaltet. Mir persönlich gefällt die Aluhut-Zone am besten 
Y2k38 - Das Jahr 2038 Problem · Y2k38 - Das Jahr 2038 ProblemY2k38 – Das Jahr 2038 Problem weckt Erinnerungen an den Millenium-Bug Y2k. Diesmal wird es schlimmer. Die Epochalypse droht!
Replied in thread
@minterpunct The classical unixes, yes.
Modern unixes (unixlikes if you will) have 64-bit time_t (#OpenBSD switched in their 5.5 release https://www.openbsd.org/55.html back in 2014, also see https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html. Others were on the way then. #time_t #y2038 #unix #freebsd #netbsd #linux
www.openbsd.orgOpenBSD 5.5OpenBSD 5.5
The Year 2038 Problem and glibc: A Comprehensive Overview
The Year 2038 Problem, often referred to as the "Unix Y2K Problem," is a critical issue affecting software and systems that rely on 32-bit signed integers to represent time.
Read More: https://machaddr.substack.com/p/the-year-2038-problem-and-glibc-a
GIF
Continuing to work through the wide variety of time formats in #OracleSolaris to see which may have #Y2038 problems, and reached the static archive format written by ar & read by ld today.
It stores timestamps for each object in the archive as an ASCII string containing a decimal number of seconds since 1970-01-01. The file format requires the string be no more than 12 characters long. "gdate --date=@100000000000" says this will be a problem in the year 33658, so I marked it okay for now.
And with that we are in the 80s of the #epochalypse[1] – at least percentage wise.
@countdownY2K38 / https://botsin.space/@countdownY2K38/112589990747088252
Solve the 
Just finished my talk at @penguicon about a history of timekeeping with an eye on the 14 years we have to prepare before the world ending in 2038. Good suggestions for edits for the next iteration of this presentation (notably to add "leap seconds" to the litany of time failures).
photo by @benny
the "remember" sticker is actually for sale by Geekenspiel https://www.ebay.com/itm/114654365152
there is a blog with occasionally timely updates: https://vielmetti.typepad.com/y2k38/
Continued thread
This was a great talk. Thank you, @w8emv! @penguicon #linux #unix #y2038
If you are using #Debian #Sid you might have noticed t64 packages coming in with the upgrades. This is an ABI upgrade implementing 64 bit time_t for all packages at once, because how would you do it otherwise. Test and implement these changes in time, we are only 15 years away from the unix epoch time issue, and Y2K even with all the testing and fixing didn't manage to fix everything in time! Some things did go wrong, and we have a fair risk that more things go wrong this time, even with these changes.
Also, do verify your code on all kinds of 32 bits time assumptions. I know many software packages have this in all kinds of places. This move by Debian is only a start and doesn't magically fix anything, in fact it mostly enables a lot of necessary fixes on protocol level that might need to happen and might need soul-searching inside your product category. For example I know that MySQL timestamps are not ready (other datefields do seem to be mostly okay) and I suppose many of your timestamp code might not be either (especially timestamp code, as this won't touch the issue until the very moment of the rollover!).
TIL about the #year2038 #2038Problem "Many systems use a 32-bit integer to store the Unix time - the number of seconds since 1 January 1970, known as the Unix epoch. On 10 January 10 2038 at 03:14:07 UTC this count will exceed the maximum value a 32-bit integer can hold, causing an overflow." 
https://en.wikipedia.org/wiki/Year_2038_problem
#Y2038 #Y2K38 #Y2K38 #epochalypse
en.wikipedia.orgYear 2038 problem - Wikipedia
Falls jemand gelegentlich hier an das #Y2K38-Problem (aka #y2038 #epochalypse) erinnert werden will, folgt @countdownY2K38
We are now 14 years away from software storing UNIX time as signed 32-bit integers overflowing and taking us back to 1901. Hopefully your software has been upgraded to store UNIX time in 64-bit integers!
en.wikipedia.orgYear 2038 problem - Wikipedia
Morgen in 14 Jahren überläuft die UNIX-Zeit auf vielen Geräten. #y2k38 #y2038 Ich höre oft das Argument, dass bis dahin kein aktuelles Gerät mehr im Einsatz ist.
Gestern habe ich einen 12 Jahre alten Fernseher weiter gegeben, um dort einen 22 jährigen Plasma zu ersetzen. Zu Hause habe ich einen ü20 Beamer. Alles FullHD 24p. Ist das jetzt besondere #nachhaltigkeit oder sind 14 Jahre doch nicht so lange? Wie sieht es bei euch aus?
@thomasfuchs @angst_ridden @hotkey @f4grx
filing away the "MySQL ambiguous year values" and "MySQL timestamp data type" problems for later, thank you
I have been intermittently collecting 2038 mitigation notes here; not really satisfied with this as a web site now, need to do something better.
https://emv-commonplace.netlify.app/y2k38/
the obligatory xkcd is 607
emv-commonplace.netlify.appCommonplace
Replied in thread
@tychotithonus @robertatcara I am trying to raise awareness of #Y2038, but the shrugs I get… I worry that we will not fix these things on time because you guys did such a phenomenal job and we will be ignored to the latest.
List of “bad” dates for OpenVMS, including Y2K and 2038:
17-Nov-1858 00:00 UTC, OpenVMS base date.
1-Jan-1970 00:00:00.00 UTC, epoch (if you see a 1969 date shown somewhere, it’s this 1970 date, shown as localtime.)
19-May-1997, the LIBRTL 10K Day limit that derailed DECwindows.
1-Jan-2000 Local, Y2K, various bugs and limits found and fixed in OpenVMS, including a then-old and now-long-since fixed limit in the ANSI magtape header specs.
2003 Local
31-Dec-2028, DEC/Compaq/HPE root certificate for layered product signatures expires. All DEC/Compaq/HP/HPE-signed layered product software installation
checks will fail to verify the kit signatures, and the checks must be overridden to permit installations. (VSI is using their own cert, so that “fun” will be saved for a date after 2028.)
19-Jan-2038 03:14:07 UTC, epoch, signed 32-bit time_t overflow. Variations of this overflow will likely be appearing in all sorts of arcane places across many platforms.
2057 Local, OpenVMS pivot date, and every century after.
7-Feb-2106 06:28:15 UTC unsigned 32-bit time_t overflow
1-Jan-10000 00:00:00.00 Local, four digit year overflows
31-Jul-31086 02:48:05.47 UTC, end of the OpenVMS epoch
Partial list, of course.
Here is one of the earlier examples of the class of 2038 bugs, this case appeared at 12-May-2006:
https://www.mail-archive.com/aolserver@listserv.aol.com/msg10315.html
“What turned out to be the problem? All these systems failed at the same time, exactly one billion seconds before the 32-bit Unix epoch ends in 2038. The timeouts set for database threads caused the software to look ahead, gasp in horror and died.”
Y2K was a mess to clean up, and I expect we’ll see the same customer compliance certification requirements starting to arrive as 2038 approaches. This will all be familiar, for those that (still) remember Y2K and the technical reviews and changes and certification paperwork that all went into preparing for Y2K, of course.
PS: Saw a video of a NASA rocket 
launch some years ago, and the launch countdown timer finished by showing the countdown as 17-Nov-1858 and not as 0. No idea what OS was driving that display. 
www.mail-archive.comRe: [AOLSERVER] aolserver 3.x not running scheduled procs anymore