[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