4 ms·

Ah, So many systems going to fail on that day for using epoch with 32 bit.

ge0rg 12y ago
Time to print our "Y2K38 consultant" business cards! :)
Someone1234 12y ago
Aren't most Linux servers already 64 bit? And we aren't even close to 2020. I'm sure some software will need to be re-written between now and 2038, but I don't think it will be quite as bad as Y2K just because that was only a 15 year gap (Sometimes less), whereas this is over 24 years. I just think a lot of software will be naturally replaced between now and then. And while there will be a slight mad scramble to fix stuff at the last minute, I don't think it is Y2K-2.
- RadioactiveMan 12y ago
  It'll definitely be interesting to see how many 32-bit embedded systems remain in use in 2038 - and what effect the overflow will have on their functionality. https://en.wikipedia.org/wiki/Year_2038_problem#Vulnerable_systems https://en.wikipedia.org/wiki/Year_2038_problem#Vulnerable_s...
  - kevin_thibedeau 12y ago
    Just as many as all of the 8-bit systems in use today. There is no need, in the vast majority of cases, for wide data busses in embedded applications. 16-bit is going to die out, though, like the 4-bit and bitslice processors.
- btilly 12y ago
  People who think that 64-bit servers are immune are part of the problem. Even if you've got a 64-bit server, you've still got file formats with 32 bit timestamps embedded. For that reason, time_t remains a 32 bit integer, which means that functions like UNIX_TIME on MySQL will stop working. And then there is the mess of embedded software that most decidedly is NOT 64-bit and will be in machines that are still in operation. See http://en.wikipedia.org/wiki/Year_2038_problem http://en.wikipedia.org/wiki/Year_2038_problem for a basic overview. None of this stuff is unfixable. But it is a real problem, and tracking it down will be hard.
codezero 12y ago
I did tech support when the 99->00 switch happened, got paid 3x overtime. I got one call, and it was actually legitimate, but was a third party piece of software so after that we left and went to a party :) I doubt this will be a real problem in 2038, then again the prevalence of computing devices is much larger now and will continue to grow by 2038, but so will technical aptitude, so hopefully they'll cancel out and this will still not be a problem.
- robin_reala 12y ago
  Same, but 4x overtime here :) I was just on the PC team though so I left at 7pm after finishing the last few BIOS updates; the AS400 and HP-UX teams got the pleasure of staying past midnight.
0x0 12y ago
I set the clock to one minute before time_t overflow on an iMac once. Recovering from that and just getting the machine to boot afterwards was no joke.
- mtrpcic 12y ago
  What version of the iMac was this? Surely modern OSX has already converted to a more appropriate storage mechanism for the date?
  - q3k 12y ago
    I'm not a XNU hacker, but it looks like they haven't. Their time_t typedef seems to be a __darwin_time_t [1], which in turn looks like to be 32-bit signed long [2]. As far as I know, the only major operating system that has dealt with Y2038 is OpenBSD [3]. [1] - https://github.com/opensource-apple/xnu/blob/bb7368935f659ada117c0889612e379c97eb83b3/bsd/sys/_types/_time_t.h#L30 https://github.com/opensource-apple/xnu/blob/bb7368935f659ad... [2] - https://github.com/opensource-apple/xnu/blob/bb7368935f659ada117c0889612e379c97eb83b3/bsd/i386/_types.h#L120 https://github.com/opensource-apple/xnu/blob/bb7368935f659ad... [3] - http://www.openbsd.org/55.html http://www.openbsd.org/55.html , http://www.undeadly.org/cgi?action=article&sid=20130813072244 http://www.undeadly.org/cgi?action=article&sid=2013081307224...
    - justincormack 12y ago
      NetBSD fixed 2038 a couple of years before OpenBSD. Made less fuss over it though.
  - 0x0 12y ago
    It was some years ago, I can't remember if it was a 32bit or a 64bit intel. Probably of the OSX 10.6/10.7 vintage.

ge0rg 12y ago

Time to print our "Y2K38 consultant" business cards! :)

Aren't most Linux servers already 64 bit? And we aren't even close to 2020. I'm sure some software will need to be re-written between now and 2038, but I don't think it will be quite as bad as Y2K just because that was only a 15 year gap (Sometimes less), whereas this is over 24 years. I just think a lot of software will be naturally replaced between now and then. And while there will be a slight mad scramble to fix stuff at the last minute, I don't think it is Y2K-2.

RadioactiveMan 12y ago
It'll definitely be interesting to see how many 32-bit embedded systems remain in use in 2038 - and what effect the overflow will have on their functionality. https://en.wikipedia.org/wiki/Year_2038_problem#Vulnerable_systems https://en.wikipedia.org/wiki/Year_2038_problem#Vulnerable_s...
- kevin_thibedeau 12y ago
  Just as many as all of the 8-bit systems in use today. There is no need, in the vast majority of cases, for wide data busses in embedded applications. 16-bit is going to die out, though, like the 4-bit and bitslice processors.
btilly 12y ago
People who think that 64-bit servers are immune are part of the problem. Even if you've got a 64-bit server, you've still got file formats with 32 bit timestamps embedded. For that reason, time_t remains a 32 bit integer, which means that functions like UNIX_TIME on MySQL will stop working. And then there is the mess of embedded software that most decidedly is NOT 64-bit and will be in machines that are still in operation. See http://en.wikipedia.org/wiki/Year_2038_problem http://en.wikipedia.org/wiki/Year_2038_problem for a basic overview. None of this stuff is unfixable. But it is a real problem, and tracking it down will be hard.

codezero 12y ago

I did tech support when the 99->00 switch happened, got paid 3x overtime. I got one call, and it was actually legitimate, but was a third party piece of software so after that we left and went to a party :) I doubt this will be a real problem in 2038, then again the prevalence of computing devices is much larger now and will continue to grow by 2038, but so will technical aptitude, so hopefully they'll cancel out and this will still not be a problem.

robin_reala 12y ago
Same, but 4x overtime here :) I was just on the PC team though so I left at 7pm after finishing the last few BIOS updates; the AS400 and HP-UX teams got the pleasure of staying past midnight.

0x0 12y ago

I set the clock to one minute before time_t overflow on an iMac once. Recovering from that and just getting the machine to boot afterwards was no joke.

mtrpcic 12y ago
What version of the iMac was this? Surely modern OSX has already converted to a more appropriate storage mechanism for the date?
- q3k 12y ago
  I'm not a XNU hacker, but it looks like they haven't. Their time_t typedef seems to be a __darwin_time_t [1], which in turn looks like to be 32-bit signed long [2]. As far as I know, the only major operating system that has dealt with Y2038 is OpenBSD [3]. [1] - https://github.com/opensource-apple/xnu/blob/bb7368935f659ada117c0889612e379c97eb83b3/bsd/sys/_types/_time_t.h#L30 https://github.com/opensource-apple/xnu/blob/bb7368935f659ad... [2] - https://github.com/opensource-apple/xnu/blob/bb7368935f659ada117c0889612e379c97eb83b3/bsd/i386/_types.h#L120 https://github.com/opensource-apple/xnu/blob/bb7368935f659ad... [3] - http://www.openbsd.org/55.html http://www.openbsd.org/55.html , http://www.undeadly.org/cgi?action=article&sid=20130813072244 http://www.undeadly.org/cgi?action=article&sid=2013081307224...
  - justincormack 12y ago
    NetBSD fixed 2038 a couple of years before OpenBSD. Made less fuss over it though.
- 0x0 12y ago
  It was some years ago, I can't remember if it was a 32bit or a 64bit intel. Probably of the OSX 10.6/10.7 vintage.