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

[Andy Lutomirski <luto@amacapital.net>]

On Mon, May 5, 2014 at 11:33 AM, John Stultz <john.stultz@linaro.org> wrote:
> I'd like to discuss some thoughts on how to address the 2038 issues on
> 32bit architectures. This is important, as vendors are still producing
> lots of 32bit hardware, which may very well have 24+ year lifespans
> (think industrial control applications, security systems).  NetBSD and
> OpenBSD have recently broken their ABI, converted their time_t to long
> long, to properly address this. So I'd like to discuss thoughts on how
> Linux can do similar despite our no-breaking-userspace rules, after all,
> one way or another (almost) all of Linux's 32bit architectures are
> terminally broken past 2038.
>
> Thomas (who I don't think can attend due to other plans) and I have had
> some small talks about this and we have different initial preferences on
> how to go about solving things, so I'd like to present the pros and cons
> of the current options we're stewing on, open the discussion up to other
> ideas, and see if there's a consensus on which way to go.

I'm interested in this discussion.

It would be nice to try to do something about the seconds, nanoseconds
representation in clock_gettime at the same time.  One way or another,
a lot of programs will continue to expect to see seconds and
nanoseconds, but it's simpler and faster to be able to feed userspace
a nanosecond count.

Also, leap seconds :(

--Andy