Just saw it for the first time today. We have a cert that expires in 2041, but a 32-bit Windows device said it expired in 1905 and rejected it.
In the next 22 years, it's upgrade to 64-bit code or die. For us, OK, most of the 32-bit stuff will be EOL long before that.
But... for the developers...
:developers:
it's a big unix issue too. the end of time. 03:14:07 UTC on 19 January 2038
And 64-bit code doesn't solve it if the software still uses a 32-bit date field.
Y2K all over again,
"The sky is falling"
- Chicken Little
For those that don't undertand the reference
http://www.worldstory.net/en/stories/chicken_little.html
Yeah, and that Y2K stuff was serious business for lots and lots of consultants. It was a license to print money for all the guys that did COBOL programming... turns out, it was their last chance to do so, but they knew it, so they ran with it.
Had a strange problem on a new Juniper EX-2300 today. It was a new install and had a two-port LACP-uplink. I was configuring it from home last week and lost connectivity immediately after trying to configure NTP. Today I went over there -good thing they aren't using it yet- and after some checks I couldn't find anything wrong with the interface configuration. The only thing off was the clock. For some reason, it had its date set to somewhere in 2038 - this thread was the first thing that popped into my mind when I saw that :) After manually configuring the clock to 2017 the LACP link came up and it successfully synchronized via NTP.
I was kind of in a rush and didn't log my console session, will try to reproduce it next week. :)
Aaaaaand, it's s a bug...
https://kb.juniper.net/InfoCenter/index?page=content&id=KB31358&actp=RSS
We're going to start to see more of these pop up as the years go by.
Yeah, but we're in 2017 still, not in 2038. Why would a device boot with its clock set to 2038, unless it's some remnant of in-house testing that remained in the code?
not worried, I'll probably be worm food by then....
Quote from: SimonV on February 03, 2017, 03:02:45 AM
Yeah, but we're in 2017 still, not in 2038. Why would a device boot with its clock set to 2038, unless it's some remnant of in-house testing that remained in the code?
It went to the end of the date field, maybe some huge value passes to that register and makes it all crazy go nuts.
When are we going 128-bit?
Quote from: Dieselboy on April 07, 2017, 02:04:04 AM
When are we going 128-bit?
Probably in 2045, after we realize that the joker that invented the 64-bit date field made it include picoseconds and it runs out on March 27th, 2047, or something like that.