[Ksummit-discuss] [CORE TOPIC] Dealing with 2038

Daniel Phillips d.phillips at partner.samsung.com
Wed May 7 01:56:22 UTC 2014


On 05/06/2014 02:56 PM, Luck, Tony wrote:
>> and going out with the sign bit set. Perhaps some logging mechanism
>> would be helpful in setting up audit systems to use in sandbox testing
>> and triage on Jan 1, 2038, with a view to clawing back the sign bit.
> We can't wait till Jan 2038 to commit a change - programs want to
> work with dates in the future - allegedly the first Y2038 bugs began
> appearing in 2008 when banks issuing 30 year mortgages were unable
> to print the correct date for final payment.
> -Tony
To clarify, sandbox testing can and should start any time. The "triage" 
part attempts to answer the question: what about bad behavior that 
somehow slips through the net and manifests only on the day of 
reckoning? The idea is to provide admins the ability to monitor their 
systems and spot issues at source as opposed to letting things go 
silently wrong and potentially cause problems far downstream. Another 
way of saying it: what way is there to be sure that the problematic 
interfaces are no longer being used, other than monitoring them? It's 
clear this is the responsible thing to do, what is less clear is whether 
the task could benefit from kernel help. Say, CONFIG_Y2038_PARANOIA.

Regards,

Daniel


More information about the Ksummit-discuss mailing list