|
|
Subscribe / Log in / New account

Approaching the kernel year-2038 end game

Approaching the kernel year-2038 end game

Posted Jan 31, 2020 16:05 UTC (Fri) by excors (subscriber, #95769)
In reply to: Approaching the kernel year-2038 end game by S8iDH5QTk
Parent article: Approaching the kernel year-2038 end game

That might be okay for representing the current time, because device lifetimes are short enough that you can hardcode the current epoch in them. E.g. radio clocks in the UK use a signal that encodes the year as 2 digits. If a device manufactured in 2020 sees the year "50" transmitted, it knows that must mean 2050 not 1950. It would misinterpret the signal in 2150 but there's no chance the device will survive that long anyway.

But that doesn't work when referring to distant past/future times, which the kernel sometimes needs to do. Your computer in 2038 might have files that were genuinely last modified in 1970, and you don't want "ls" to start saying they were modified in 2106. 64-bit timestamps are pretty cheap and they completely solve that problem without the need for heuristics.

It's like how "Jan 31" might be good enough when arranging a holiday with someone, because you both interpret it relative to the same 'now'; but if you print out your holiday photos and put them in an album, you probably want to write "Jan 31 2020" on them, else when you look back in future years you won't have the context to interpret them correctly.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds