the most headache inducing issues by far are going to be file formats and network protocols that integrate 32bit unix timestamps, which are numerous.

NTP is one such example.

This is a much worse and much more fundamental issue than the y2k bug was, I hope people aren't writing off the severity, the time to start dealing with it is now.

Agreed, it's pretty scary. On the other hand, I'm sure similar problems were tackled for y2k with the 2-digit fields everywhere. If we built it, we can rebuild it. Although a lot of software and hardware will need replacing/upgrading/switching over to new protocols.

They were, however, given that a lot of things have life in the field of several decades, now is the time to start fixing it so it doesn't become a mad rush. Yes, it means less money for devs 23 years from now as they madly rush to update software, but I'd rather that money be spent for devs to make future programs awesome than to worry about our ghosts.

NTP doesn't use unix timestamps but an other format. It will hit the bug 2 years earlier.

If I see the 2038 problem in a newspaper headline I think I'm going to take the closer fire exit.

Indeed. I get worried when I see people deploying new embedded ARM systems these days to replace systems that are 30 years old when there is only 24 years to 2038...

It seems bit odd that they are so proud of 64-bit time_t that they even made their release song about that, with this sentence in the description:

> In the same way, the road is paved for the 64-bit time_t transition. Other operating systems can now make this jump

Haven't Linux and FreeBSD been on 64bit time_t for like 10 years now?

I can't speak for Linux/FreeBSD, but NetBSD has been 64-bit time_t (all ports)[0] since 6.0, which was Oct 2012[1].

[0] https://www.netbsd.org/releases/formal-6/NetBSD-6.0.html

[1] https://www.netbsd.org/about/history.html

not on 32 bit systems, which is what that part of the release announcement is about.

All unix 64bit systems have a 64bit time_t, only OpenBSD and NetBSD at this point have 64bit time_t on 32 bit systems.

This cannot be changed on Linux without breaking userland ABI/API compatibility, something which the maintainers refuse to do.

Except x32 systems, as that issue had to be tackled before integration into the linux kernel.

But x32 doesn't work on 32-bit systems

oh, 32 bit systems, I do remember those good old beige boxes :)

yeah, I know, those silly ARM chips have been bit on the slow side getting on the 64bit train.

If you install a 32-bit Linux, then time_t is still 32-bit, only on 64-bit Linux you get 64-bit time_t. Although by 2038 I hope we won't have many 32-bit systems around...

Embedded devices are likely to be 32-bit for a very long time yet. I'd consider 100+ years to be a reasonable number!

64-bit devices are much more complicated (bus size, peripherals, part count) and therefore more expensive. If your entire task fits in a 32-bit space there is little motivation to use a 64-bit core.

> 64-bit devices are much more complicated (bus size, peripherals, part count) and therefore more expensive

I don't see why 64 bit core would imply any additional external complexity? Didn't 68k have 32bit core and work just fine down to 8bit external bus?

It won't on full SoC devices but most ARM embedded devices of that sort have all sorts of peripherals which are bus connected so the bus will need to be external.

If it ain't broke...There are still 8 bit and 16 bit cores being produced today. Hoping products will become obsolete is one of the big reasons y2k was a problem.

I think one of the points from OpenBSD is that 32 bit systems will be around. Legacy system are one thing, but how about embedded systems.

Manufacturers will want to use 32bit processors in new system for a long long time, simply because they can save a few cents.