Linux 5.1 Continues The Years-Long Effort Preparing For Year 2038 (phoronix.com)

← Back to Stories (view on slashdot.org)

Linux 5.1 Continues The Years-Long Effort Preparing For Year 2038 (phoronix.com)

Posted by msmash on Tuesday March 5, 2019 @07:30AM from the tussle-continues dept.

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.

118 comments

Min score:

Reason:

Sort:

it seems early but it's not by Anonymous Coward · 2019-03-05 07:36 · 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.
1. Re:it seems early but it's not by DontBeAMoran · 2019-03-05 07:38 · Score: 1
  
  No time to waste, guys! There's only 19 years left!
  
  --
  #DeleteFacebook
2. Re:it seems early but it's not by darkain · 2019-03-05 07:45 · Score: 1
  
  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!
3. Re:it seems early but it's not by Anonymous Coward · 2019-03-05 07:48 · Score: 0
  
  Oddly enough, I think it's a bit late. Not too late to fix the problem, but late in the sense that this should have already been fixed by now. I remember hearing about this in about 1998. I think it was first addressed in the kernel quite a long time ago (early 2000s?) Why is it still being fixed in the kernel in 2019?
4. Re: it seems early but it's not by Anonymous Coward · 2019-03-05 07:51 · Score: 1
  
  Some current mortgages and bonds will last longer than that. No need to wait for 19 years for issues to appear.
5. Re: it seems early but it's not by Anonymous Coward · 2019-03-05 07:57 · Score: 0
  
  You're expecting humans to have working brains and not do stupid shit. We're fucked.
6. Re: it seems early but it's not by Anonymous Coward · 2019-03-05 07:58 · Score: 1
  
  Because all the Linux devs have been focusing on user experience.... oh
7. Re:it seems early but it's not by jfdavis668 · 2019-03-05 08:17 · Score: 1
  
  No, there's 595666616 seconds left.
8. Re:it seems early but it's not by skullandbones99 · 2019-03-05 08:19 · Score: 1
  
  You are too late already, it is 18 years and so many months. It is definitely not 19 years....
9. Re:it seems early but it's not by DontBeAMoran · 2019-03-05 08:33 · Score: 2
  
  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.
  
  --
  #DeleteFacebook
10. Re:it seems early but it's not by DontBeAMoran · 2019-03-05 08:34 · Score: 1
  
  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!
  
  --
  #DeleteFacebook
11. Re:it seems early but it's not by ceoyoyo · 2019-03-05 08:38 · Score: 4, Funny
  
  Y10K bug.
12. Re: it seems early but it's not by Joe_Dragon · 2019-03-05 08:52 · Score: 1
  
  no days left will rollover to an negative number and he will get out right away.
13. Re:it seems early but it's not by fuzznutz · 2019-03-05 08:57 · Score: 1
  
  How much is that in parsecs? I got a Kessel run I got to make before my navi-computers lose their mind.
14. Re: it seems early but it's not by Anonymous Coward · 2019-03-05 08:58 · Score: 0
  
  Great if just the date is good enough for you. Some calculations do need the number of seconds and leap seconds are impossible to predict.
15. Re: it seems early but it's not by Anonymous Coward · 2019-03-05 09:00 · Score: 0
  
  Because all the Linux devs have been focusing on user experience.... oh
  systemd will take care of it.
16. Re: it seems early but it's not by dougdonovan · 2019-03-05 09:05 · Score: 0
  
  how often do you tune up your car ? treat your computer like you treat your car and both will be in good shape by 2038.
17. Re:it seems early but it's not by Kjella · 2019-03-05 09:44 · Score: 1
  
  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.
  
  --
  Live today, because you never know what tomorrow brings
18. Re: it seems early but it's not by bn-7bc · 2019-03-05 11:00 · 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
19. Re: it seems early but it's not by marka63 · 2019-03-05 11:15 · Score: 1
  
  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).
20. Re: it seems early but it's not by Anonymous Coward · 2019-03-05 12:17 · Score: 0
  
  Actually we are going to repeal that amendment and he will still be president. Bwahahahaha!
21. Re: it seems early but it's not by Anonymous Coward · 2019-03-05 12:21 · Score: 0
  
  Negative days served means he was innocent. Ask Ben Bernanke about negative numbers, he'll tell you. He's an expert on the Great Depression.
22. Re:it seems early but it's not by Anonymous Coward · 2019-03-05 12:27 · Score: 0
  
  SCO? What did you do, steal it from Autozone? The HPs will be fine. When they finally explode their corpses will be functional Okidata320s.
23. Re:it seems early but it's not by arglebargle_xiv · 2019-03-05 14:15 · Score: 1
  
  Windows actually got this pretty right, they just made time_t 64 bits when they switched to Win64 and everything works as required. Linux kinda missed that window some time ago, unfortunately.
24. Re: it seems early but it's not by Anonymous Coward · 2019-03-05 19:40 · Score: 0
  
  systemd will take care of it.
  Yeah. Poettering will just close all related bugs with a "It's not systems fault, your calendar is broken." comment, and force everyone to switch to a calendar based on HIS birth date.
25. Re:it seems early but it's not by skullandbones99 · 2019-03-05 21:04 · Score: 1
  
  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 calendar date but some counties such as Russia use the 7th January as Christ's birthday because that is the old calendar equivalent date.
  Also 0001-01-01 never was a real date because the Gregorian calendar never existed at that time. 1 BC used the Julian calendar and there is a mismatch in days between the Gregorian and Julian calendars due to the different lengths of each of their "years" plus various leap days. I suspect that 0001-01-01 is in 1 BC because of this mismatch.
26. Re:it seems early but it's not by skullandbones99 · 2019-03-05 21:28 · Score: 1
  
  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-bit glibc to be modified to use these new Y2038 tolerant system calls. But in addition, 32-bit applications will need modifying to use the new glibc library calls.
  Linux has not missed the opportunity. Linux will be supporting upgraded 32-bit applications to run on a 32-bit or 64-bit Linux kernel via a 32-bit glibc.
  Due to the closed source binary only nature of the Windows Eco-system, I expect many 32-bit applications will not be compliant for Y2038.
27. Re:it seems early but it's not by petermgreen · 2019-03-05 21:58 · Score: 1
  
  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.
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
28. Re:it seems early but it's not by arglebargle_xiv · 2019-03-05 23:25 · Score: 1
  
  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 is some legacy apps running on a 64-bit base OS.
  Since Windows already has a massive infrastructure present that exists to provide shims for broken apps, I'm assuming significant time_t breakage will be addressed the same way if there's anything left by 2038.
  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.
29. Re: it seems early but it's not by Anonymous Coward · 2019-03-06 01:42 · Score: 0
  
  windows is not in embedded systems? sure. +99% of all power plant control systems use windows. ditto chemical plants. avg life is well beyond any of these dates.
30. Re:it seems early but it's not by DontBeAMoran · 2019-03-06 02:02 · Score: 1
  
  Damn, foiled again!
  
  --
  #DeleteFacebook
31. Re:it seems early but it's not by ebh · 2019-03-06 07:00 · Score: 1
  
  And people wonder why tzdata gets updated so often...
32. Re: it seems early but it's not by ebh · 2019-03-06 07:04 · Score: 1
  
  I find that I can go less and less time before I have to set the floppy drive's timing and dwell...
33. Re:it seems early but it's not by hawk · 2019-03-06 07:18 · Score: 1
  
  > 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 outside of the US still *use* the old calendar.
  hawk
34. Re: it seems early but it's not by Anonymous Coward · 2019-03-08 06:10 · Score: 0
  
  Whooooooooosh
35. Re: it seems early but it's not by Anonymous Coward · 2019-03-08 06:30 · Score: 0
  
  I presume that computers use the Gregorian calendar for all dates including before the Gregorian calendar was invented in October 1582.
  You have obviously never typed cal 09 1752 on a linux/unix system.
36. Re: it seems early but it's not by Anonymous Coward · 2019-03-08 06:35 · Score: 0
  
  How often do I tune up my car?
  About as often as I buy a new vehicle with a carburetor.
37. Re:it seems early but it's not by skullandbones99 · 2019-03-09 01:13 · Score: 1
  
  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.
38. Re:it seems early but it's not by skullandbones99 · 2019-03-09 02:46 · Score: 1
  
  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 protocol may be used to identify the NTP EPOCH era, however, old NTP clients might not of implemented this workaround.
  It was standard practice for Linux systems to initialise the system clock to the UNIX EPOCH date of 1st January 1970 (system clock starts at 0) which subsequently got updated during boot-up via a real-time clock (RTC) and/or NTP. The 68 year maximum delta + the UNIX EPOCH date of 1st January 1970 gives a maximum resolvable date in 2038. But if the NTP client assumes the original NTP EPOCH of 1 January 1900 due to the Y2036 role-over then 1900 is more than 68 years from 1970 and this gap cannot be correctly represented. There are many embedded systems that do not have an RTC so without mitigation (see below), these systems cannot set correct dates after Y2036 hits.
  To compound this issue, Y2038 hits preventing correct dates from being used anyway. Systems may be using erroneous dates around 1900 or 1970.
  The NTP v4 failure mode has been mitigated against by no longer initialising the system clock to the UNIX EPOCH date of 1st January 1970 during boot-up, instead the system clock is initialised to the build time and date of the kernel. This reduces the risk of the NTP 68 year maximum time delta from being exceeded as it is unlikely that the same kernel is in use for 68 years (but you never know). Some systems also save the system clock value upon shutdown and set the system clock back to this value when booting-up. This migration should cause the NTP client to use the new NTP EPOCH because dates earlier than the build date are invalid as the build date can be relied upon as being a valid snapshot in time.
Linux 23.1.4 by SurenEnfiajyan · 2019-03-05 07:39 · Score: 1

I wonder if Linux will survive to this date even without this problem.
1. Re:Linux 23.1.4 by Anonymous Coward · 2019-03-05 07:49 · Score: 0
  
  Linux is deployed on most of the smartphones and cloud servers in existence. What's even on the horizon to challenge it? If anything I'd see it becoming the underpinning of Windows, MacOS and iOS before any of those replaced it.
2. Re:Linux 23.1.4 by MightyYar · 2019-03-05 07:51 · Score: 1
  
  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.
  
  --
  W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
3. Re:Linux 23.1.4 by SurenEnfiajyan · 2019-03-05 07:56 · Score: 1
  
  Linux is deployed on most of the smartphones
  Google is working on its replacement. As for servers, it's hard to say, even today some companies use other OSes for that.
4. Re:Linux 23.1.4 by Anonymous Coward · 2019-03-05 12:32 · Score: 0
  
  Even before I looked I knew it would be a BSD license...
  Apple gleaned from NetBSD too. Hope they handed out some iTunes gift cards in thanks.
5. Re:Linux 23.1.4 by arglebargle_xiv · 2019-03-05 14:20 · Score: 1
  
  Everyone is always working on the next big thing OS. Can't remember the last time when one of these actually took off... literally every single one has failed, the core always ends up being either BSD (1970s), Windows (1980s), or Linux (1990s, the most recent).
Luckily I will be retired by then.... by buffcleb · 2019-03-05 07:39 · Score: 1

only 12 years left... not that I'm counting...
1. Re:Luckily I will be retired by then.... by Anonymous Coward · 2019-03-05 07:51 · Score: 0
  
  You're clearly not counting because it's 19 years away. 12 isn't even correct in hexadecimal.
2. Re: Luckily I will be retired by then.... by Anonymous Coward · 2019-03-05 07:56 · Score: 0
  
  He's saying he will be retired in 12 years you fucking idiot. Learn to read.
3. Re:Luckily I will be retired by then.... by lazarus · 2019-03-05 07:58 · Score: 1
  
  You may not be counting in base10. You may be right in base16 depending on exactly when in 2038 it happens.
  
  --
  I am not interested in articles about life extension advancements.
4. Re:Luckily I will be retired by then.... by Merk42 · 2019-03-05 08:04 · Score: 1
  
  So you plan to go completely off the grid and not rely on any Linux powered technology once you retire in 12 years?
5. Re:Luckily I will be retired by then.... by Anonymous Coward · 2019-03-05 08:18 · Score: 0
  
  I interpreted his comment as 'luckily I won't have to deal with all the work for this' (with a potential rider: unless they feel like paying me huge wads of cash to come back as a private contractor who does not have to deal with any phb nonsense).
6. Re:Luckily I will be retired by then.... by skullandbones99 · 2019-03-05 08:25 · Score: 1
  
  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.
7. Re:Luckily I will be retired by then.... by ceoyoyo · 2019-03-05 08:44 · Score: 1
  
  He could go off the grid, still use Linux, and just pretend it's 1999.
8. Re:Luckily I will be retired by then.... by Anonymous Coward · 2019-03-06 01:38 · Score: 0
  
  Every base is 10 when using the local dialect. You have to say something like "You may not be counting in base 10 decimal" or "You may not be counting in base ten."
Opportunity to Learn by execthis · 2019-03-05 07:43 · Score: 1

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 by Anonymous Coward · 2019-03-05 07:44 · Score: 1

-typedef time_t int
+typedef time_t long
There. Fixed it.
1. Re: You're trying way too hard by Anonymous Coward · 2019-03-05 07:55 · Score: 0
  
  The kernel is only one part of the OS. Lots of libraries and apps to fix too. Let's not forget interop with other programming languages which only see int or long in C libraries.
2. Re:You're trying way too hard by Carcass666 · 2019-03-05 07:56 · Score: 1
  
  While you're at it, why use a signed type at all?
3. Re: You're trying way too hard by Anonymous Coward · 2019-03-05 08:02 · Score: 0
  
  I would HOPE they'd be re-writing and deprecating those old libraries before 2038 regardless of this problem, jesus...
4. Re: You're trying way too hard by Anonymous Coward · 2019-03-05 08:08 · Score: 0
  
  I wouldn't count on it.
5. Re: You're trying way too hard by Anonymous Coward · 2019-03-05 08:14 · Score: 0
  
  Because you need to subtract time in order to measure duration and elapsed time. Changing between signed and unsigned types is going to lead you to more bugs than just letting everything roll over in 2038.
6. Re:You're trying way too hard by vovin · 2019-03-05 08:20 · Score: 1
  
  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 explicit sized time_t typedefs:
  typedef __s64 time64_t;
  typedef __u64 timeu64_t;
  So the humorous OP was actually just wrong anyway :P
  Also note that with GCC on Linux and most UNIX platforms, a long is 64 bits on a 64 bit arch, on Windows the long type is 32 bits on a 64 bit arch (LLP64).
7. Re:You're trying way too hard by Anonymous Coward · 2019-03-05 08:41 · Score: 0
  
  Because it isn't just used to represent the exact time and this very moment.
  It is also used to represent historic dates, some that are before the epoch start.
  If you only install and configure your system you won't need that, but if you use your computer for actual work that has with the real world to do and isn't just limited to making the computer run better you might need negative timestamps.
  Or a timestamp that starts at the same time as the universe, but that seems impractical and might break with new discoveries.
  Main problem I see with the way we handle time is that leap seconds are added directly to the global timestamp instead of handled as part of the local time.
  Since things like earthquakes and other events impacts the leap second it makes it a bit cumbersome to use together with interplanetary communication if we ever should want a calendar based on Mars years or whatever.
8. Re:You're trying way too hard by Anonymous Coward · 2019-03-05 08:51 · Score: 0
  
  If you find yourself needing that last one bit - you're doing something.
9. Re: You're trying way too hard by Anonymous Coward · 2019-03-05 11:20 · Score: 0
  
  Parent said:
  "Main problem I see with the way we handle time is that leap seconds are added directly to the global timestamp instead of handled as part of the local time."
  Absolutely. Once you have modified your master clock (Unix system time) by adding in leap seconds, you have an ambiguous clock.
  There are hacks to try to recover an unambiguous past time by looking up a historical leap second database, but they are mostly wishful thinking in that they can never totally recover time down to the second for most practical scenarios.
  The only way to have full second accuracy would be to have a unix system clock without leap seconds. The most practical standard might be GPS time, but even TAI (International Atomic Time) could be used. They are identical to UTC except they are off by a certain number of seconds, that number being determined by the moment when the standard was in sync with UTC. Leap seconds added to UTC since that moment account for the difference.
10. Re:You're trying way too hard by Anonymous Coward · 2019-03-05 21:31 · Score: 0
  
  It is already defined as long BUT long is not guaranteed to be 64 bits long in the C standard. Thanks for playing.
11. Re: You're trying way too hard by nukenerd · 2019-03-05 22:40 · Score: 1
  
  The kernel is only one part of the OS.
  Found the RMS comment.
12. Re:You're trying way too hard by Megane · 2019-03-06 04:58 · Score: 1
  
  So how do you tell the difference between -1 as an error and -1 as one second before the epoch? History didn't start in 1970, and a good number of humans still alive today were born before then.
  
  --
  #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Linux will not exist in 2038 by Anonymous Coward · 2019-03-05 07:55 · Score: 0

The use of SystemD has ensured that FreeBSD will beat out Linux for all servers by 2038. Suck it, freetards.
1. Re:Linux will not exist in 2038 by Anonymous Coward · 2019-03-05 08:12 · Score: 0
  
  Has this been confirmed by netcraft?
2. Re:Linux will not exist in 2038 by jfdavis668 · 2019-03-05 08:15 · Score: 1
  
  By that time FreeBSD will be running launchd, which is basically the same thing.
3. Re: Linux will not exist in 2038 by Anonymous Coward · 2019-03-05 08:21 · Score: 0
  
  FreeBSD made their own systems clone based on the same concepts. And OpenBSD was forced to implement a bunch of wrappers to emulate enough of systemd in order to get gnome-session to run.
4. Re:Linux will not exist in 2038 by Anonymous Coward · 2019-03-05 10:13 · Score: 0
  
  OpenBSD, then. Theo would never go in for anything like systemd.
5. Re:Linux will not exist in 2038 by Megane · 2019-03-06 04:59 · Score: 1
  
  It won't have been written by Lennart Poettering. And that's a good thing.
  
  --
  #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Year 2038 by Anonymous Coward · 2019-03-05 08:00 · Score: 0

The year of Linux
it's too late by Anonymous Coward · 2019-03-05 08:03 · Score: 0

Without proper patches and firmware for deprecated platforms the work done on 5.0 branch is meaningless.
Routers, TVs, video recorders, CCTVs, and more will be non-functional in 2038. And there is nothing we can do to stop it.
The only option that remains: Open a new savings account with your bank and put money into it for the next 19 years to replace all your useless equipment.
1. Re:it's too late by jeff4747 · 2019-03-05 08:15 · Score: 3, Insightful
  
  Ya know, I think you can survive with the timestamp on your CCTV feed having the wrong year.
2. Re:it's too late by Kjella · 2019-03-05 09:48 · Score: 3, 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?
  
  --
  Live today, because you never know what tomorrow brings
3. Re:it's too late by petermgreen · 2019-03-05 22:07 · Score: 2
  
  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.
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
4. Re:it's too late by skullandbones99 · 2019-03-05 22:13 · Score: 1
  
  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.
5. Re: it's too late by Anonymous Coward · 2019-03-08 06:43 · Score: 0
  
  I guarantee your stinking VCR will still be blinking 12:00 come Jan 20 2038.
Problem will hit before 2038 by ardmhacha · 2019-03-05 08:25 · 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,
1. Re:Problem will hit before 2038 by twdorris · 2019-03-05 08:50 · Score: 4, 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...
2. Re:Problem will hit before 2038 by bill_mcgonigle · 2019-03-05 10:56 · Score: 3, 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.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Pension age... by casperghst42 · 2019-03-05 08:42 · Score: 1

Many who are have been hired the last 20 years will be going on pension well after 2038 ... you need to store the date in something - many have resulted in storing dates in strings, which is less than perfect.
1. Re:Pension age... by Anonymous Coward · 2019-03-05 09:07 · Score: 0
  
  I wonder if such cases are really related with OS. To me it seems purely DBs and other user side applications, not OS, issue. I suppose OS mostly deals with current and immediate future times at best. In what ways OS may use quite far future times?
Well we need to come in Saturday and Sunday + TPS by Joe_Dragon · 2019-03-05 08:54 · Score: 1

Well we need to come in Saturday and Sunday to keep up + WE need to talk about your TPS reports!
What took you so long? by macraig · 2019-03-05 08:57 · Score: 1

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.
1. Re:What took you so long? by Michael+Woodhams · 2019-03-05 17:12 · Score: 4, 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.
  
  --
  Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
2. Re:What took you so long? by macraig · 2019-03-05 18:24 · Score: 1
  
  Your last sentence summarizes the value well enough: SORTING!
3. Re:What took you so long? by Anonymous Coward · 2019-03-06 13:21 · Score: 0
  
  Except you got it backwards. Year at the end is BIG ENDian. Years are bigger than days.
4. Re: What took you so long? by Anonymous Coward · 2019-03-08 06:15 · Score: 0
  
  That isnt what big-endian means. In big-endian MSB (big end) comes first, not last.
And when will we get around to fixing Y10K? by Anonymous Coward · 2019-03-05 09:01 · Score: 0

I suppose as usual we're going to wait until the year 9990 before we start kicking ourselves for using "only" four digits for the year.
Sooo... Elephant in the RooM by Anonymous Coward · 2019-03-05 09:04 · Score: 0

What happens to a NIX machine if you set your clock to this now or past it?
What about Kernels that haven't had ANY mitigation? After this mitigation? With the other kernel mitigation?
Specifics? Get Technical with it in terms of memory usage and addresses?
1. Re:Sooo... Elephant in the RooM by Megane · 2019-03-06 05:07 · Score: 1
  
  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.
  
  --
  #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
The Year of Linux on the Desktop by Anonymous Coward · 2019-03-05 09:15 · Score: 0

2038?
Linux 10.0 by crow · 2019-03-05 09:41 · Score: 1

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.
1. Re:Linux 10.0 by skullandbones99 · 2019-03-05 21:58 · Score: 1
  
  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!
2. Re:Linux 10.0 by fbobraga · 2019-03-06 03:48 · Score: 1
  
  Linus will be 68 yers old on 2038...
3. Re:Linux 10.0 by hawk · 2019-03-06 07:21 · Score: 1
  
  > not 23.1.
  I'm pretty sure it will be version 20.38 . . . :)
  hawk
Oh good by blackt0wer · 2019-03-05 10:44 · Score: 1

19 years to rebuild Linux from Scratch
1. Re:Oh good by skullandbones99 · 2019-03-05 22:26 · Score: 1
  
  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.
2. Re:Oh good by fbobraga · 2019-03-06 03:52 · Score: 1
  
  Na href=https://en.wikipedia.org/wiki/Google_Fuchsia>Google Fuchsia...
3. Re:Oh good by fbobraga · 2019-03-06 03:53 · Score: 1
  
  Fixing the link (forgot to preview the post...): Google Fuchsia
linux still struggling with this? by iggymanz · 2019-03-05 17:05 · Score: 1

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.
1. Re:linux still struggling with this? by zyche · 2019-03-05 17:50 · Score: 1
  
  This is the comment that should be pegged at the top.
2. Re:linux still struggling with this? by Anonymous Coward · 2019-03-06 01:15 · Score: 0
  
  That works great except for that one developer that needed to convert that time_t into something that "int 0x1A" can handle. That is number of days since Jan 1, 1980 & 32-bit tick count with 18.206 ticks per second.
  Anyone who believes that all time in Linux is time_t is simply wrong. Time routinely needs conversions into other formats for various devices. That could include things like NTP (64-bit seconds from Jan 1, 1900) or GPS (10-bit week with "1 = Jan 6, 1980" + seconds into the week). There are direct mathematical relationships between these time values, but you cannot necessarily get to them solely via the time_t type. This is especially true when you start considering leap years and leap seconds.
  Combine that with some sloppy programming practices where people simply chose to use another type and things can get messy quickly.
3. Re:linux still struggling with this? by yet+another+SanTiago · 2019-03-06 01:58 · Score: 1
  
  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).
4. Re:linux still struggling with this? by iggymanz · 2019-03-09 07:06 · Score: 1
  
  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
You impetuous young whippersnappers! by Michael+Woodhams · 2019-03-05 17:26 · Score: 1

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 weird stuff happening in SCCS. It turned out that the server they were using had SCCS via someone just copying over the binaries, rather than correctly installing them, so when it got its Y2K-compliant OS upgrade, those binaries were not replaced, and were not Y2K-compliant. I was able to diagnose the problem, patch the dozen or so source code commits which they'd made with the bad binaries, and call in a sysop to install the correct binaries. (I didn't have root on that server.)

--
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
Re:Problem will hit before 2038 - Try 1970! by Anonymous Coward · 2019-03-05 18:28 · Score: 0

The company where I worked had written a computer system in 1963 with a one digit year and tested the date when entered at startup to be greater than 3.
Along came 1970.
Luckily, they still had programers, now managers, who know how to fix it.
I think "Mr. T." & crew do a good job by Anonymous Coward · 2019-03-06 01:08 · Score: 0

See subject: I've had a NEW Mac-Mini for 2 months & haven't "fired it up" & why? KUbuntu 18.04 w/ current patches LTS model!
I really LIKE it!
(Does ALL I need...)
IF they keep up this level of improvement (1994 Slackware 1.02 was my start, sucked/no GUI (due to no hardware support for a "Windows Accelerator card" Diamond Stealth 14 ISA back then)/crude dev tools & apps - then Redhat 1999 (got better but not much imo), then KUbuntu 10.10 in 2010 (very close, pretty good but "no cigar" UNTIL 18.04 LTS I note above, for me))?
* Hey: I MAY NEVER FIRE UP THAT MAC (no, not true, but it IS my liking Linux that IS HOLDING ME BACK (from producing a port of my APK Hosts File Engine to 64-bit MacOS)).
APK
P.S.=> THAT is a statement unto itself imo - from ME, practically the "former poster child" for Windows (1991-2018 user & was a large part of my career as a software-engineer/programmer-analyst)... apk
Re:I think "Mr. T." & crew are doing a good jo by Anonymous Coward · 2019-03-06 01:17 · Score: 0

Good job APK running /. weezils DRY of "downmodpoints" by reposting https://linux.slashdot.org/com... + good job https://tech.slashdot.org/comm... burning 'em w/ fact!
Thanks - however? apk by Anonymous Coward · 2019-03-06 01:23 · Score: 0

See subject: I don't consider it a 'great accomplishment' to expose their DULL menial DOLT 'brain' so easily - they're just STUPID constantly proving it vs. me SO easily defeating their bs @ every turn & EVERY level, lol!
* LMAO (can't help it: great way to start everyday & yes, this happens everyday):
All they HAVE is their EFFETE useless 'downmods' vs. me (since they surely lack the technical prowess to take me down on that level) & as you saw, I just repost & EXHAUST their dimwit tactics, lol (limited downmodpoints are like them - LIMITED - me? No limits on repost OR ability to DUST them easily!).
APK
P.S.=> I love it - why? It's SO easy to do & they make ME look GOOD & themselves like the LIMITED MENIAL DOLTS they are (serious wastes of life)... apk