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

["H. Peter Anvin" <hpa@zytor.com>]

On 05/05/2014 01:53 PM, josh@joshtriplett.org wrote:
> 
> I would be interested in this, not just because of time_t itself, but as
> a general pattern for "how can we transition away from an old and broken
> ABI".  Whether by introducing new system calls, new personalities,
> seccomp filters, or other mechanisms, we should have some ways to start
> such transitions and to smooth them out.  Sure, we never break
> userspace, but that just means we need an appropriate
> CONFIG_OLD_AND_BUSTED option for as long as people still need the old
> ABI.
> 

There is absolutely nothing new here... we have dealt with these kinds
of transitions for most of Linux' existence.

However, time_t is a particularly nontrivial issue, because it is not
just a matter of changing the kernel ABI but a *lot* of user space ABIs
also contain this type.  The kernel/glibc interfaces are pretty well set
up to handle this properly these days, but I have very little hope that
all the user space libraries will properly handle having two versions of
a bunch of APIs with different version numbers.

On the other hand, a *limited* form of compatibility could be had by
changing the windowing by changing int32_t (1901-2038) to uint32_t
(1970-2106).  This is similar to how a lot of legacy applications were
"fixed" for the Y2K problem.

That has its own share of problems, in particular legacy applications
might end up thinking that 2039 comes long before 2037, but there is to
some degree a choice of plague or cholera, as we say in Swedish.

	-hpa