https://github.com/dotnet/runtime/blob/f2a9ef8d392b72e6f039ec0b87f3eae4307c6cae/src/native/libs/System.Native/pal_datetime.c#L38C13-L38C13

SystemNative_GetSystemTimeAsTicks suffers from the Y2038 issue. This is, I would guess, expected.

Sample code:

Console.WriteLine("Hello, World!");
while (true)
{
Thread.Sleep(2000);
Console.WriteLine("DateTime (UTC): {0}", DateTime.UtcNow);
}

Build and then run the above on a 32bit ARM platform (in this case running Debian 11 armhf with Linux kernel 5.15.99, using .net8 runtime) .

My results during the rollover:

DateTime (UTC): 1/19/2038 3:14:01 AM
DateTime (UTC): 1/19/2038 3:14:03 AM
DateTime (UTC): 1/19/2038 3:14:05 AM
DateTime (UTC): 1/19/2038 3:14:07 AM
DateTime (UTC): 1/1/1970 12:00:00 AM
DateTime (UTC): 1/1/1970 12:00:00 AM
DateTime (UTC): 1/1/1970 12:00:00 AM
DateTime (UTC): 1/1/1970 12:00:00 AM
DateTime (UTC): 1/1/1970 12:00:00 AM
DateTime (UTC): 1/1/1970 12:00:00 AM

Opening this case for tracking purposes. At some point the powers in charge will need to sync up with Debian efforts, which are still a work in progress. Related Debian notes: https://wiki.debian.org/ReleaseGoals/64bit-time .

I would guess that at some point .net would obsolete support for systems with 32bit time_t and require 64bit time_t.