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

[Theodore Ts'o <tytso@mit.edu>]

On Thu, May 08, 2014 at 09:37:06PM +0100, Ben Hutchings wrote:
> 
> LFS is far from universally supported by applications, 17 years after it
> was standardised.  In fact, many applications recently regressed due to
> a broken test for LFS in autoconf <https://bugs.debian.org/742780>.  It
> doesn't seem like a good example to follow.

Yes, that was my point.

> However this is done, almost every library that includes time_t in its
> API will change ABI.  I say 'almost' because glibc will probably use
> symbol versioning or mangling to maintain binary compatibility, but most
> library maintainers won't go to that trouble.

Agreed.  This is why I'm not sure anything other than a hard ABI break
is realistic.  Yes, it's incredibly painful, and the distro's will
probably be very unhappy, but I suspect the alternatives are worse.
The only real question is do we start trying to deal with the pain
now, or in 2020, or in 2030, or 2035, or even worse, in 2037....

Given what what I saw with Y2K, if I was going to participate in a
betting pool on the question, I'd probably put my money down for 2035
or so.  :-/

     	   	       	     	      	 - Ted