It's the time of the century we should start worrying about Y2K38
-
@The_Quiet_One said in What users say versus what they mean:
The only thing that's missing is the "Y2K Compliant" sticker.
This reminded me, is it?
Recently colleague was cleaning up some code where static analysis pointed out thread-unsafe use of
gmtimeandstrftime. Well, this is an IoS device (canonically; it even runs a component called <somename> IoT Gateway), based on a CortexA8 ARMv7 chip, that is going to be built into something which usually has projected lifetime well over 20 years.So I wanted to ask
- Are you already worrying about Y2K38 problems in some project of yours?
- And do you have any suggestion for “correct” solution for Linux C++ code that needs to work correctly on 32-bit (but may be used on 64-bits too)?
-
@Bulb Lobby for introduction of a
time64_tand associated system calls?
-
I would be worried about this but Ios devices probably won't last until their warranty runs out.
-
@Bulb said in It's the time of the century we should start worrying about Y2K38:
Are you already worrying about Y2K38 problems in some project of yours?
No. Those that care about times have already been fixed.
And do you have any suggestion for “correct” solution for Linux C++ code that needs to work correctly on 32-bit (but may be used on 64-bits too)?
Have you checked what the size of
time_tis? On at least some platforms, it's already 64 bits wide (and so isn't affected by Y2K38 at all). I don't have a convenient way to check on modern Linux right now.FWIW, the main concern is going to be times in “preserved data” (e.g., tar archives) and those could be handled by recognising that the time information is coming from an old source and sign-extending it appropriately.
-
@PleegWat said in It's the time of the century we should start worrying about Y2K38:
@Bulb Lobby for introduction of a
time64_tand associated system calls?I think it actually exists, but as far as I've looked so far it seems it is only available on 32-bit versions, and not always.
@DogsB said in It's the time of the century we should start worrying about Y2K38:
I would be worried about this but Ios devices probably won't last until their warranty runs out.
This is an industrial device. I did mention the typical lifetime of the kind of machine it is going to be built into is upwards of 20 years (I'm guessing 30–50).
@dkf said in It's the time of the century we should start worrying about Y2K38:
Have you checked what the size of time_t is? On at least some platforms, it's already 64 bits wide (and so isn't affected by Y2K38 at all).
On some platforms yes. For example iOS. But not on Linux. Linux has binary backward compatibility all the way back to the versions from 1993 or so (though its standard C library has it only to versions from around 1998).
-
@PleegWat said in It's the time of the century we should start worrying about Y2K38:
@Bulb Lobby for introduction of a
time64_tand associated system calls?Just get this rubber-stamped:
GitHub - evalEmpire/y2038: Fix time.h on 32 bit machines to work past the year 2038 bug
Fix time.h on 32 bit machines to work past the year 2038 bug - evalEmpire/y2038
-
@Bulb said in It's the time of the century we should start worrying about Y2K38:
@DogsB said in It's the time of the century we should start worrying about Y2K38:
I would be worried about this but Ios devices probably won't last until their warranty runs out.
This is an industrial device. I did mention the typical lifetime of the kind of machine it is going to be built into is upwards of 20 years (I'm guessing 30–50).
I find that unlikely that they'll be there that long but I'm worked in safety devices which had a planned obsolescence of 10 years. Twenty years has me worried. On the bright you have an opportunity here. Find a solution for the problem. Put a date in your diary for sometime in 2036 and charge an astronomical day rate to fix the problem.
-
@DogsB said in It's the time of the century we should start worrying about Y2K38:
Put a date in your diary for sometime in 2036
Who the fuck buys their diaries 18 years in advance!?
-
@Gąska said in It's the time of the century we should start worrying about Y2K38:
@DogsB said in It's the time of the century we should start worrying about Y2K38:
Put a date in your diary for sometime in 2036
Who the fuck buys their diaries 18 years in advance!?
Someone who is going to make a mint fixing Y2k38 problems apparently.
I use Google calendar for everything so that wouldn't be completely unrealistic for me. the most forward thinking I've done is last year when I bought tickets to Elton John for 2020. So
-
@Bulb said in It's the time of the century we should start worrying about Y2K38:
@The_Quiet_One said in What users say versus what they mean:
- Are you already worrying about Y2K38 problems in some project of yours?
No. We don't do many calendar-related things besides "create date" and "modify date" and maybe scheduling up to 6 months in the future. For sure, if our software had stored dates that far into the future for scheduling purposes, we'd probably take a harder look at it, but also seeing we're a .NET Core shop with no Unix timestamps being used, more of our concern would be with any third-party vendors that are not compatible.
-
@DogsB said in It's the time of the century we should start worrying about Y2K38:
I find that unlikely that they'll be there that long but I'm worked in safety devices which had a planned obsolescence of 10 years.
Yeah, the safety-serious devices I worked with on previous project are only live as long as their batteries, which is under 10 years, but they had support for years all the way until 2100 in requirements. But they had the luxury of being fully custom firmware in the device—so free to choose the time format—and the application runs on tablet and can—and must—be updated. Also iOS has 64-bit time_t and Android seems to have some limited support for time64_t. But plain Linux does not seem to...
@JBert said in It's the time of the century we should start worrying about Y2K38:
GitHub - evalEmpire/y2038: Fix time.h on 32 bit machines to work past the year 2038 bug
Fix time.h on 32 bit machines to work past the year 2038 bug - evalEmpire/y2038
It seems Perl is using the thing.
-
@Bulb said in It's the time of the century we should start worrying about Y2K38:
@JBert said in It's the time of the century we should start worrying about Y2K38:
GitHub - evalEmpire/y2038: Fix time.h on 32 bit machines to work past the year 2038 bug
Fix time.h on 32 bit machines to work past the year 2038 bug - evalEmpire/y2038
It seems Perl is using the thing.
Don't worry, it's not contagious.
-
@DogsB said in It's the time of the century we should start worrying about Y2K38:
@Gąska said in It's the time of the century we should start worrying about Y2K38:
@DogsB said in It's the time of the century we should start worrying about Y2K38:
Put a date in your diary for sometime in 2036
Who the fuck buys their diaries 18 years in advance!?
Someone who is going to make a mint fixing Y2k38 problems apparently.
I use Google calendar for everything so that wouldn't be completely unrealistic for me. the most forward thinking I've done is last year when I bought tickets to Elton John for 2020. So
Thinking a google product will not be abandoned in the next 20 years.
-
@topspin said in It's the time of the century we should start worrying about Y2K38:
@DogsB said in It's the time of the century we should start worrying about Y2K38:
@Gąska said in It's the time of the century we should start worrying about Y2K38:
@DogsB said in It's the time of the century we should start worrying about Y2K38:
Put a date in your diary for sometime in 2036
Who the fuck buys their diaries 18 years in advance!?
Someone who is going to make a mint fixing Y2k38 problems apparently.
I use Google calendar for everything so that wouldn't be completely unrealistic for me. the most forward thinking I've done is last year when I bought tickets to Elton John for 2020. So
Thinking a google product will not be abandoned in the next 20 year.
Funnily enough I've being thinking of moving this stuff to outlook calendar which I pay for.
I've moved almost everything else into the Microsoft ecosystem so I may as well move that too.
-
@DogsB said in It's the time of the century we should start worrying about Y2K38:
outlook calendar
Thinking a
google>Microsoft product will not beabandonedrebranded 10 times in the next 20 years.You mean, .Net Passport 365 MSN Live Calendar for Business?
-
@Applied-Mediocrity said in It's the time of the century we should start worrying about Y2K38:
@DogsB said in It's the time of the century we should start worrying about Y2K38:
outlook calendar
Thinking a
google>Microsoft product will not beabandonedrebranded 10 times in the next 20 years.You mean, Microsoft .Net Passport 365 MSN Live Calendar for Business Azure?
FTFY
-
@Applied-Mediocrity said in It's the time of the century we should start worrying about Y2K38:
@DogsB said in It's the time of the century we should start worrying about Y2K38:
outlook calendar
Thinking a
google>Microsoft product will not beabandonedrebranded 10 times in the next 20 years.You mean, .Net Passport 365 MSN Live Calendar for Business?
I've no idea what it's called now. Does the url and my login work? Good! That's all I need to know.
I've being using hotmail.com to get into shit for years.
-
@Bulb said in It's the time of the century we should start worrying about Y2K38:
CortexA8 ARMv7 chip, that is going to be built into something which usually has projected lifetime well over 20 years.
That seems very high, unless this is a special high-life product? Guaranteed flash data-retention is only 10 years generally. And use of wet electrolytics in SMPSs can potentially knobble you well before then.
Edit: I'm working on a SIL-2 long-life system at the moment, it is a gigantic pain in the ass to design.
-
@Cursorkeys said in It's the time of the century we should start worrying about Y2K38:
That seems very high, unless this is a special high-life product?
Ok, I went to look at the specification, and it says mean time between failures at least 200,000 hours. Provided there is no hard life limit that would be over 22 years (which I don't see mentioned, but it does not completely prove it does not exist).
That is the supposed-to-be production hardware. We now have just prototype one. It is completely different. As in, the prototyping in a Contex-A8 ARM, the production will be Intel x86…
-
@Bulb said in It's the time of the century we should start worrying about Y2K38:
As in, the prototyping in a Contex-A8 ARM, the production will be Intel x86…
-
@Bulb said in It's the time of the century we should start worrying about Y2K38:
Are you already worrying about Y2K38 problems in some project of yours?
We're too busy belatedly worrying about whether or not we're affected by the Y2K19 bug that's going to happen on Saturday.
-
@dkf Also, looking up the CPU specified in the production hardware data sheet, it is actually x86-64, so that solves the problem
.It also means we've done huge amount of utterly useless work—the software is already running on some x86 targets, but wasn't used on ARM before and some of the teams were struggling to set up the cross-compilation for their component. And now we are going to simply run it on something that is almost exactly like the desktop, to the point it's going to use Ubuntu. Would have been much easier for everybody. So yes,
3.
-
@DogsB said in It's the time of the century we should start worrying about Y2K38:
@Gąska said in It's the time of the century we should start worrying about Y2K38:
@DogsB said in It's the time of the century we should start worrying about Y2K38:
Put a date in your diary for sometime in 2036
Who the fuck buys their diaries 18 years in advance!?
Someone who is going to make a mint fixing Y2k38 problems apparently.
I use Google calendar for everything so that wouldn't be completely unrealistic for me.
-
I work on some stuff that will fail at 2099, some at 2155. But they are easy enough to bump to another 50 or 100 years when it happens.
-
@Gurth said in It's the time of the century we should start worrying about Y2K38:
@DogsB said in It's the time of the century we should start worrying about Y2K38:
@Gąska said in It's the time of the century we should start worrying about Y2K38:
@DogsB said in It's the time of the century we should start worrying about Y2K38:
Put a date in your diary for sometime in 2036
Who the fuck buys their diaries 18 years in advance!?
Someone who is going to make a mint fixing Y2k38 problems apparently.
I use Google calendar for everything so that wouldn't be completely unrealistic for me.
I'm not sure about the paid option now.
Microsoft Closing eBook Store, Refunding all Past Purchases | The eBook Reader Blog
Today Microsoft announced that they will be closing their ebook store for good as of April 2nd, 2019. Considering how unpopular it was that's not surprising, but what is surprising is the fact that they've decided to delete all ebooks from user accounts and issue refunds for past purchases and pre...
-
So with this upcoming GPS version of the Mayan calendar end-of-world, is there any way to determine if your device will be affected?
-
@hungrier I've gotten the impression it's mostly old devices (no updates for years) that will be affected. Since the rollover is this weekend, I'd recommend wait and pray.
-
@PleegWat More importantly, does it only affect devices in use at the time of the overflow, or is everything fucked forever afterwards?
-
@PleegWat I'm not too worried about any of my devices, but my dad has an old GPS that he takes on trips because it's easy to side-load maps from OSM. Maybe I can finally convince him to use his phone for that.
-
@sockpuppet7 said in It's the time of the century we should start worrying about Y2K38:
I work on some stuff that will fail at 2099, some at 2155. But they are easy enough to bump to another 50 or 100 years when it happens.
My coworker hard-coded daylight saving into some of his stuff, it's very brittle too. In 20 years if any of that is still in use it'll just boot-loop.
Have some pride man! I know 20 years is way beyond the design life but that's just nasty.
Edit: The digital-storage oscilloscope I use at home is 24 years old and still works great. Cost as much as a luxury car when it was new...but still
-
@Cursorkeys said in It's the time of the century we should start worrying about Y2K38:
Have some pride man! I know 20 years is way beyond the design life but that's just nasty.
Well, that wasn't my choice, it's the weird operating system SDK of those thingies.
-
@topspin said in It's the time of the century we should start worrying about Y2K38:
@PleegWat More importantly, does it only affect devices in use at the time of the overflow, or is everything fucked forever afterwards?
Yes.
