Moonchild wrote: ↑
Considering the actual date where this is needed is 18 YEARS away, they should reconsider breaking everything and demanding that all Linux software developers double their workload.
I think that the Y2K panic taught people a lesson about not putting off things to the last minute. As for "double the workload", it'll probably be a short transition thing. When software devs do get serious, applications, with 32-bit time_t will simply stop being available. I believe that ssl certificate expiry dates tend to be in the order of several months, not years. But RSA certificates are another story. According to https://techcommunity.microsoft.com/t5/ ... a-p/272758
a 4096-bit key can be valid for up 16 years into the future (i.e. 2036). Breaking that breaks ssh. Remember that the first kernel drop will probably require some debugging, so they'll be cutting things a bit close for comfort.
Moonchild wrote: ↑
How about instead of doing this, using those 18 years to come up with a compatible solution?
Sorry, compatability is simply not possible, for the same reason IPV6 could not be compatible with IPV4. IPV4 uses a 32-bit address. 2^32 addresses, minus reserved ranges, cannot contain the number of addresses required by 7+ billion people and a host of IDIOT (Insecurely Designed Internet Of Things) devices.
Similarly, a signed 32-bit signed integer cannot store the count of seconds from January 1, 1970 to January 20, 2038. An ugly hack that changes the interpretation of 32-bit time_t would wreak just as much havoc on existing systems as switching over to 64-bit time_t. And ugly hacks tend to come back to bite you in the ass eventually. A really quick-n-dirty solution to Y2K on 2-digit-year systems was "windowing". The original code interpreted 00...99 as 1900...1999 internally. The code was modified to interpret 00...19 as 2000...2019 and 20...99 as 1920...1999. Along comes January 1st, 2020... oops... https://www.usatoday.com/story/tech/202 ... 419535002/
Lesson learned... do it right the first time.