8 ms·
We're 16 years away from the overflow. In other words, some of the systems being put in production right now are going to be around, untouched, unchanged, when
by tgsovlerkhgsel 5y ago
We're 16 years away from the overflow. In other words, some of the systems being put in production right now are going to be around, untouched, unchanged, when it happens.
Given this article, it seems we're still doing it wrong, and that means... 2038 will be "fun" (either the remediation, or the consequences of the lack thereof).
At least most of us in the industry now have a good retirement plan: Fixing the legacy systems in 16 years...
- jandrese 5y agoIronic that so many people are hoping to retire before they get asked to deal with this mess since so much medical equipment is built on ancient and poorly maintained microcontroller environments.
- deleted 5y ago[deleted]
- treesknees 5y agoWhich part is ironic?
- jandrese 5y agoThe irony of retiring to avoid the problem only to have it become a problem with the equipment keeping you alive in retirement.
- Animats 5y agoWe're 16 years away from the overflow. In other words, some of the systems being put in production right now are going to be around, untouched, unchanged, when it happens. Yes. It's getting close. Windows XP, released in 2001, still had a significant presence in 2017, 16 years after introduction.[1] 42% of companies still had some XP systems running back then. 11% of machines were still running it. [1] https://community.spiceworks.com/networking/articles/2719-windows-10-adoption-who-s-using-it-two-years-after-launch https://community.spiceworks.com/networking/articles/2719-wi...
- Beltiras 5y agoThankfully upgrades move faster in the OSS world. The worrysome cases are embedded systems. Especially those built intentionally 32 bit.
- masklinn 5y ago... TFA is about how GNU/Linux systems being deployed right now are not Y2038-safe. Windows applications have been safe from this issue by default starting from VC8.0 (VS 2005), macOS users since 10.7. And to be fair Linux itself has used 64b time_t on 64b machines from the start (and since 5.6 — last year — has also migrated i386 to 64b time_t[0], though a few issues will remain forever). [0] https://lkml.org/lkml/2020/1/29/355?anz=web https://lkml.org/lkml/2020/1/29/355?anz=web
- btown 5y ago> upgrades move faster in the OSS world There are many who don’t think like this. Microsoft has dedicated teams that ensure backwards compatibility for legacy applications, and even then people stay on XP. If you have an inherited Ubuntu system that has been happily running a proprietary binary for years, there’s even less guarantee (and certainly no marketing organization making that guarantee) that an upgrade won’t break things. And so you fall far behind LTS.
- zymhan 5y agolaughs in debian au contraire, it's quite easy to keep museum-level ancient Linux distros running
- azernik 5y agoYour desktop Linux distro is not the scary case here
- kevin_thibedeau 5y agoThings will start breaking in 2036 when NTP rolls over. Then everyone will wonder why they didn't have two years left.
- onei 5y agoI have no clue how widely implemented it is, but as far as NTP is concerned we're currently in era 0 which spans from 1900 to 2036. When we reach 2036, we just move to era 1 and have another 136 years until we reach era 2. NTP itself should be resilient to this kind of issue by design.
- floatingatoll 5y agoChances are, based on how poorly leap seconds and TLS 1.3 (and, I predict, http3/udp) are handled in actual reality by deployed systems, that a variety of software and hardware will fail inside infrastructure worldwide when ntp ticks over to era 2. https://news.ycombinator.com/item?id=28046997 https://news.ycombinator.com/item?id=28046997 https://news.ycombinator.com/item?id=13750379 https://news.ycombinator.com/item?id=13750379 https://news.ycombinator.com/item?id=27402222 https://news.ycombinator.com/item?id=27402222
- xattt 5y agoHow many eras are possible in NTP?
- grogers 5y agoInfinitely many IIRC. Era isn't sent in the protocol, it's determined implicitly - if you know the time correctly to within a few dozen years you know the right era
- foxfluff 5y agoSo a device made in 2021 whose (1970 based?) RTC battery drained has no idea which era it is in 2036. Perfect.
- zaphirplane 5y agoWouldn’t there be things that have future values set, like financial/insurance to name a few
- funcDropShadow 5y agoThey and everybody else should avoid using timestamp representations for any dates so far in the future. Because, it is a nightmare to translate timestamps when the timezone database is updated. Which you would have to do, if e.g. the EU finally manages to get rid of summer time and you care that dates past that change stay the same.
- mindwok 5y agoWhat’s the alternative to a timestamp representation?
- wyufro 5y agoA string, ISO 8601, https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601 Preferably RFC3339 (which is a specific profile of ISO 8601) but, as noted in a sibling comment, it isn't always appropriate for future dates.
- aulin 5y agowait, why? unix timestamps are safe from this kind of mess as they are UTC seconds since the epoch, all the tz-aware conversion happens when you need to display localized dates but the timestamp you save should be as neutral and tz-unaware as possibile. I've seen way more bugs from people assuming system clock to be UTC while it was localized. Like missing and overwritten data on daylight saving changes.
- davrosthedalek 5y agoThe problem is that the contract normally doesn't specify epoch seconds. So if the translation of UTC since epoch to local time changes, the local time specified in the contract does not, so your UTC since epoch timestamp has to.
- PixelOfDeath 5y agoxfs filesystem being mounted at BLABLABLA supports timestamps until 2038 (0x7fffffff) Hmmm...
- deleted 5y ago[deleted]
- cesarb 5y ago> In other words, some of the systems being put in production right now are going to be around, untouched, unchanged, when it happens. Most of these systems being put in production right now will be using 64-bit distributions, which have always used 64-bit time_t. Most of the rest will be using embedded distributions, which often use something other than glibc. So only a fraction of these systems "being put in production right now [which] are going to be around" will be affected.
- xyzzy_plugh 5y agoThis is false. Many, many embedded systems simply use glibc. I wouldn't go so far as to say "most" embedded systems do not use glibc.
- DiabloD3 5y agoI don't know of any embedded systems still using glibc. Dietlibc, uclibc (used by openwrt and the other consumer router replacement firmwares), musl libc, and bionic (since Android is technically an embedded Linux, so should be mentioned as well) dominate the embedded Linux space.
- Unklejoe 5y agoI do embedded development and I use Glibc on all of our products. It's as simple as checking the box in Buildroot, so why not? The version of Glibc I am using has special accelerated memcpy and string functions for my CPU (e6500 PPC, Altivec).
- ahartmetz 5y agoOpenEmbedded / Yocto / whatever (it's complicated) uses glibc, and that's a quite popular distribution construction kit.
- jcelerier 5y agoI don't remember ever being involved with embedded not using glibc if it was using any sort of Linux.
- plank 5y agoPerhaps. But things like Log4j might help us: while in the previous century (2k problem) making a potential problem largely go completely away, it might be that in 10 years such an endeavor may be a simple task.
- rst 5y agoThere are also applications which might reasonably have to process dates 16 years in the future right now. I suspect most of finance, for instance, is on 64-bit systems at this point, or we'd be hearing a little bit more about this.
- dathinab 5y agoDateTime processing and system time are often handled separately with some system time to datetime time conversion.