At January 19, 2038 03:14:07 GMT the UNIX epoch time will end.

No it won't end. The number type will be changed to 8 bytes imho

>>59241773
That's only an issue for 32-bit devices and OpenBSD's already got it fixed

Isn't it already changed to 64 bits even on 32-bit computers?

>>59241831
>That's only an issue for 32-bit devices

It's also an issue for 64-bit devices that use file formats or protocols that contain any time_t data in their formats.

>>59241825
>No it won't end. The number type will be changed to 8 bytes imho

The problem is that they've known about this problem for many years, but they haven't even proposed standard new names that can be used to replace time_t and all the other things that depend on it.

Once the new names are decided on, then we'll need a libc rolled out that implements them.

Once that happens, then the developers will have a standard way of upgrading all the apps, file formats, and protocols from time_t to use the new standard name.

The whole process should have been given at least 30 years from start to finish. (That's because file formats and protocols are the most affected, which have the longest lifespans.) But at the pace they're going, they won't have nearly that long to prepare. Their incompetent laziness will result in a huge panic in the final few years -- plus, every solution will be custom hacked by the individual engineers because there will be no universal standard libc solution in place. Their unwillingness to act and take leadership on creating a standard libc solution is one of the most astounding demonstrations of stupidity I have ever seen in my career. (Sure, there are a few different "time.h drop-in replacements" out there, but nothing that has been blessed by the standards bodies, and nothing that is available in the standard libc.)