Linux 5.1 Continues The Years-Long Effort Preparing For Year 2038 (phoronix.com) 118
Linux 5.1 continues the massive undertaking in preparing the kernel for the Year 2038 problem. Phoronix: The Linux kernel has been seeing "Y2038" work for years and the effort is far from over. Thomas Gleixner (a Linux kernel developer who serves as a member of the technical advisory board at The Linux Foundation) sent in the latest Y2038 work for the Linux 5.1 kernel, which after a lot of ground work in previous kernels has introduced the first set of syscalls that are Year 2038 safe.
it seems early but it's not (Score:5, Insightful)
We know from y2k that systems have a long lifetime. Software needs to be fixed well before 2038 to ensure that they work then, especially with Linux in so many embedded systems that make much more use of time data.
Good on them.
Re: (Score:2)
No time to waste, guys! There's only 19 years left!
Re: it seems early but it's not (Score:1)
Some current mortgages and bonds will last longer than that. No need to wait for 19 years for issues to appear.
Re: (Score:2)
no days left will rollover to an negative number and he will get out right away.
Re: (Score:2)
Re: (Score:2)
That's a huge number which gives the impression there's even more time left.
You need to do the opposite: there's only 0.19 century left!
Re: (Score:2)
Re: it seems early but it's not (Score:1)
Well as parsecs messure distance and not time it is kind of hardto convert between the units, â" oh it was a joke, Iâ(TM)m terrible at geting them at times, butthsnk you for the effort weneed a bit of humpr here. Have a nice day
Re: (Score:2)
You are too late already, it is 18 years and so many months. It is definitely not 19 years....
Re: (Score:3)
You may be too late, but I'm not. I've been storing dates as ISO8601 strings for over a decade now, to bypass all the Pre-1970-01-01/Y2000/Y2038 bullshit. All my systems can go from 0000-01-01 to 9999-12-31.
Re:it seems early but it's not (Score:5, Funny)
Y10K bug.
Re: (Score:2)
Damn, foiled again!
What took you so long? (Score:2)
You're tardy, fella. I began using the ISO8601 - or "Asian" - date format way back in the (Nineteen) Eighties, likely before it was even an ISO standard. It's OBVIOUSLY the only way to store and represent dates in a fashion useful for non-human computing. Frankly, humans themselves would do well to adapt their squishy CPUs to internally represent dates in that fashion. That is still a work in progress for me, largely due to the ongoing external bombardment of non-ISO8601 insanity.
Re:What took you so long? (Score:5, Informative)
Ditto. I felt smugly superior to be using little-endian DD-MM-YYYY which was so much better (consistent) than the USA's middle-endian MM-DD-YYYY format. Then starting in 1988, my MSc thesis was on an experiment with many Japanese collaborators (they had the money, we had the supernova) and I saw them use YYYY-MM-DD and I was an instant convert. We're already big-endian in our decimal notation, so dates should be too. And in YYYY-MM-DD, chronological order and 'alphabetic' order are the same.
Re: (Score:2)
Your last sentence summarizes the value well enough: SORTING!
Re: (Score:2)
And which calculations are those? Actual examples of where it is *needed* for real problems not theoretical examples.
For timers you calculate a timer assuming a negative leap second at the end of each month in a interval so you don't overshoot, fire the timer then reset it to fire again with the leap second adjusted time as the base. Repeat if necessary (requires intervals over ~200000 years initially).
Re: (Score:2)
All my systems can go from 0000-01-01 to 9999-12-31.
I think you will find plenty systems choke on year "zero" which is actually year 1 BC. There's technically no reason why since anything before 1753 is wonky anyway and ISO 8601 allows it, but you'll have a lot less headaches with 0001-01-01 as your min-value.
Re: (Score:2)
I am guessing that the reference to 1753 is the switch-over from the Julian calendar to the Gregorian calendar but depending on your country the switch-over happened on different dates over a period of 3.5 centuries.
I presume that computers use the Gregorian calendar for all dates including before the Gregorian calendar was invented in October 1582. I always wondered whether historians converted historical dates to the Gregorian calendar. For example, Christ's birthday of 25th December is the Gregorian cale
Re: (Score:1)
And people wonder why tzdata gets updated so often...
Re: (Score:2)
> For example, Christ's birthday of 25th December is the Gregorian calendar date but some counties such
>as Russia use the 7th January as Christ's birthday because that is the old calendar equivalent date.
No, they don't in any way, shape, or form "Use" January 7th.
Rather, they use a calendar that says its December 25, while the rest of us are using January 7.
I assume that the Russians have switched to the Gregorian for secular use, but the overwhelming majority of Orthodox and most Eastern Catholics ou
Re: (Score:2)
I agree with you, you repeated my point. I should of been clearer that the 7th January was the Gregorian date which is equivalent to 25th December in the Julian calendar.
Re: (Score:2)
No shit! At my workplace, we *STILL* have a SCO Unix machine in production, along with some HP printers that just turned 20 years old in January... Y2038 is now less than 20 years away, so anything built today MIGHT be running then!
Re: it seems early but it's not (Score:1)
Because all the Linux devs have been focusing on user experience.... oh
Re: (Score:2)
Re: (Score:2)
The Y2038 issue is not restricted to time_t 64 bits so a simple upgrade to using 64-bit operating systems helps but is not the full solution. For example, filesystem timestamps and Internet protocols that use timestamps will need validating for Y2038. In other words, there will be inter-operability issues to be fixed such as the NTP Internet time protocol (Y2036 + Y2038 issues).
The work on Linux includes modifying the 32-bit Linux system calls to use 64-bit time variables. In the future, this will allow 32-
Re: (Score:2)
Windows again was lucky there, they used that weirdo format of 100ns ticks in a 64-bit counter that Dave Cutler brought over from VMS. Not saying it makes sense, but it happens to work.
I think the plan with Windows is that there won't be any 32-bit code still running by the time it becomes an issue. Unlike Linux it's not really usable as an embedded OS that'll be around forever, and MS are close to discontinuing the remaining 32-bit Windows versions (XP and Vista are already gone), so all that'll be left
Re: (Score:2)
In terms of specific protocols, NTP isn't actually that bad since it works on timestamp deltas, not absolute values. Depending on how badly the client is written you can still get problems going to the native date encoding if it's 32-bit, but it's not the hard-fail that it would appear to be.
The NTP Y2036 issue can become a hard-fail as follows:
NTP v4 uses an EPOCH of 1 January 1900 and rolls over on 7th February 2036. This is a time range of 136 years (2^32 seconds). NTP can cope with time deltas that span +/- 68 years (68 x 2 = 136 years). After the roll-over occurs in 2036, the NTP client needs to know that it is in the new time era (new NTP EPOCH date of 7th February 2036) but old software may assume the original NTP EPOCH of 1 January 1900. NTP only passes time deltas but flags in the prot
Re: (Score:2)
64-bit linux *does* have a 64-bit time_t.
y2038 is mostly an issue for 32-bit systems, not saying there won't be some issues on 64-bit systems where developers have stored times in a 32-bit types, but those issues should be relatively contained and manageable.
Re: (Score:1)
I find that I can go less and less time before I have to set the floppy drive's timing and dwell...
You impetuous young whippersnappers! (Score:2)
Back in my day, we waited 1997 and then worked excessive hours in a panic for three years. If it was good enough for us, it should be good enough for you.
I actually had a 100% genuine post-Y2K bug that I needed to fix. I was one of the main people in charge of source control (which was SCCS) in our company at the time. On 2nd Jan my on-call cell phone rang (while I was watching Sleepy Hollow in a movie theatre - oops!) A few rather keen developers were working, despite it being a holiday, and were getting w
Linux 23.1.4 (Score:2)
Re: (Score:2)
Google is working on its replacement [wikipedia.org]. As for servers, it's hard to say, even today some companies use other OSes for that.
Re: (Score:2)
Re: (Score:2)
Some incarnation of it will almost certainly be in use. Maybe it won't be in every smartphone, tablet, and car like it is now - but there will almost certainly be servers running it, even if they are called "legacy systems", and even if they are virtualized.
Linux 10.0 (Score:2)
It was almost 4 years from 4.0 to 5.0, and we're 19 years from 2038, so that puts us at somewhere around 10.0, not 23.1. Of course Linus may completely change the number system by then, so it's impossible to predict.
Re: (Score:2)
Please be precise, Y2038 occurs world-wide at 03:14:07 UTC on 19 January 2038. Therefore, there is less than 19 years to go!
Re: (Score:2)
Re: (Score:2)
> not 23.1.
I'm pretty sure it will be version 20.38 . . . :)
hawk
Luckily I will be retired by then.... (Score:1)
Re: (Score:2)
Hopefully you are not a software programmer because it is LESS THAN 19 years away. So 12 in hex is correct eg. 18 whole years away.
Re: (Score:2)
You may not be counting in base10. You may be right in base16 depending on exactly when in 2038 it happens.
Re: (Score:2)
Re: (Score:2)
He could go off the grid, still use Linux, and just pretend it's 1999.
Opportunity to Learn (Score:2)
Maybe this is an opportunity for computer science students who want to learn more about the Linux kernel see see its inner workings.
You're trying way too hard (Score:1)
-typedef time_t int
+typedef time_t long
There. Fixed it.
Re: (Score:2)
The kernel is only one part of the OS.
Found the RMS comment.
Re: (Score:2)
Re: (Score:2)
So returning -1 can be used to indicate an error?
Also time_t is already defined as a long in the linux kernel so its 64 bits on a 64 bit arch kernel and 32 for a 32 bit arch.
I think this set of syscalls is mainly for 32 bit architectures to be able to be explicit about 64 time_t values
Meaning that the implicit time_t is now the same as the explicit time64_t on 64 bit architectures while (if you care) about portability and correctness across 32/64 architectures you would start using time64_t.
Here are the 2 e
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:it's too late (Score:4, Insightful)
Ya know, I think you can survive with the timestamp on your CCTV feed having the wrong year.
Re:it's too late (Score:4, Funny)
Ya know, I think you can survive with the timestamp on your CCTV feed having the wrong year.
I will, but won't somebody please think of the NSA?
Re: (Score:2)
If your CCTV relies on NTP (Internet time protocol) then NTP rolls-over in 2036 and this is called the Y2036 issue. Then Y2038 hits on top of Y2036. Good luck with getting the correct date after that.
Re: (Score:3)
Routers, TVs, video recorders, CCTVs, and more will be non-functional in 2038. And there is nothing we can do to stop it.
We can't stop todays or yesterdays products from having problems in 2038.
But the sooner this is fixed in the main-line the sooner it will reach the production lines the less effected equipment there will be still in use in 2038.
Problem will hit before 2038 (Score:5, Insightful)
The Y2K bug hit well before the year 2000.
Back in 1990 the company I worked for had a problem when a 10 year contract with scheduled payments was entered into the system in 1990. All the programmers in the company spent weeks working through source code searching for places where dates were stored with a 2 digit year. I assume the Y2038 bug has already hit systems where future dates are used,
Re:Problem will hit before 2038 (Score:5, Informative)
It already has. Back in 2006 with some AOLServer code working around an Oracle driver bug of some sort.
http://taint.org/2006/07/20/17... [taint.org]
Re:Problem will hit before 2038 (Score:4, Insightful)
30 year mortgages were being processed in 2007 ... but they're rarely using kernel time_t for any of that. Cron jobs in 2037 might need to worry.
Pension age... (Score:1)
Well we need to come in Saturday and Sunday + TPS (Score:2)
Well we need to come in Saturday and Sunday to keep up + WE need to talk about your TPS reports!
Re: (Score:2)
If you're lucky they all get replaced by then or die from hardware failure. Or you could maintain an offset date by subtracting 50 years and paying attention every Feb 29/Mar 1. Or maybe you can throw Linux onto them!
It's not exactly a new problem. I have some old TRS-80 stuff where TRSDOS/LDOS stored the date year as a 3-bit number plus 1980.
Oh good (Score:1)
Re: (Score:2)
Nope, you have 18 years plus some months until Y2038 hits world-wide at 03:14:07 UTC on 19 January 2038. If you wait 19 years, you will be too late.
Imagine simultaneous world-wide failures predominantly in Embedded Systems when Y2038 bites.
If you try to set your smart-phone to 2039, you will find that you can't get past 2036. Why is that ? Answer Y2038.
Re: (Score:2)
Re: (Score:2)
linux still struggling with this? (Score:2)
netbsd and OpenBSD made time_t 64 bit even on 32 bit architectures. FreeBSD is a bit lamer and didn't do that for 32 bit x86.
Pathetic.
Re: (Score:2)
This is the comment that should be pegged at the top.
Re: (Score:2)
BSDs are chill with breaking API and ABI between major versions, while Linux kernel keeps them stable (or at least not intentionaly broke them), so such transition has to be more complicated (like in off_t 32->64 bit transition where there are two sets of functions / data types and programs can either explicitly use the 64-bit ones, or be recompiled with define that transparently switches to 64-bit ones).
Re: (Score:2)
Wrong, there is no "more complicated" solution that will help here.
Not an excuse when 32 bit time is ending, the API/ABI *HAS* to be broken for this one
Linux devs less capable is all