You’re right on every point. But, I’m not sure how that goes against what I said.
Most applications now use the epoch for date and time storage, and for the 2038 problem the issues will be down to making sure either tiime_t or 64bit long values (and matching storage) which will be a much smaller change then was the case for y2k. Since more people also use libraries for date and time handling it’s also likely this will be handled.
Most databases have datetime types which again are almost certainly already ready for 2038.
I just don’t think the scale is going to be close to the same.
Depends on your definition of scale, because in absolute numbers I think Y2K38 wins, even though it might be a lower percentage.
I think the main issue is not the services that are updated at least once a year, but those that run forgotten somewhere with a sticker “here be dragons” on the case.
Regardless of how many are affected, it’s gonna be fun for sure! Can’t wait for some public government and ad company screens to inevitably show certificate errors.
I think it’ll be a “we’ll see” situation. This was the main concern for y2k. And I don’t doubt there’s some stuff that was partially patched from y2k still around that is still using string dates.
But the vast majority of software now works with timestamps and of course some things will need work. But with y2k the vast majority of business software needed changing. I think in this case the vast majority will be working correctly already and it’ll be the job of developers (probably in a panic less than a year before as is the custom) too catch the few outliers and yes some will escape through the cracks. But that was also the case last time round too.
You’re right on every point. But, I’m not sure how that goes against what I said.
Most applications now use the epoch for date and time storage, and for the 2038 problem the issues will be down to making sure either tiime_t or 64bit long values (and matching storage) which will be a much smaller change then was the case for y2k. Since more people also use libraries for date and time handling it’s also likely this will be handled.
Most databases have datetime types which again are almost certainly already ready for 2038.
I just don’t think the scale is going to be close to the same.
Depends on your definition of scale, because in absolute numbers I think Y2K38 wins, even though it might be a lower percentage.
I think the main issue is not the services that are updated at least once a year, but those that run forgotten somewhere with a sticker “here be dragons” on the case.
Regardless of how many are affected, it’s gonna be fun for sure! Can’t wait for some public government and ad company screens to inevitably show certificate errors.
I think it’ll be a “we’ll see” situation. This was the main concern for y2k. And I don’t doubt there’s some stuff that was partially patched from y2k still around that is still using string dates.
But the vast majority of software now works with timestamps and of course some things will need work. But with y2k the vast majority of business software needed changing. I think in this case the vast majority will be working correctly already and it’ll be the job of developers (probably in a panic less than a year before as is the custom) too catch the few outliers and yes some will escape through the cracks. But that was also the case last time round too.