Re: Y2038 proposal

Stephen John Smoogen

On Wed, 30 Nov 2022 at 03:08, Alexander Kanavin <alex.kanavin@...> wrote:
On Tue, 29 Nov 2022 at 16:45, Stephen Jolley <> wrote:
> We’d welcome a proposal/series on how to move forward with the Y2038 work for 32 bit platforms.

I have the following proposal:

1. A branch is made where:
a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally.
b. qemu is always started with "-rtc base=2040-01-01", simulating
Y2038 actually occurring.
c. an additional runtime test verifies that both RTC clock and system
clock report 2040.

Going from various problems I saw with systems with smaller time wraps, setting a time after wrap occurs misses most of the problems which wall occur. Many systems will work fine with either 'negative' or 'smaller dates' but crash, burn, etc when running when the counter wraps around. I would suggest setting the test date to -N minutes before wrap over to run a first set of tests, and then N minutes after the wrap to run a second set of tests. This would hopefully catch programs which are worse off.

Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren

Join { to automatically receive all group messages.