ARM32 Year 2038 issue

[mattheweshleman]

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.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-datetime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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) .

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.

Author:	mattheweshleman
Assignees:	-
Labels:	area-System.DateTime
Milestone:	-

[MichalPetryka]

The code could maybe check whether __clock_gettime64 is supported by the compiler and use that.

[am11]

@janvorli fixed this issue for musl-libc in https://github.com/dotnet/runtime/pull/50105/files and other PRs. The assumption was that we are already using 64-bit time for glibc and musl-libc wasn't updated.
Perhaps we just need to set _TIME_BITS=64 globally next to

runtime/eng/native/configurecompiler.cmake

Lines 440 to 441 in fac60d0

	# Unconditionally define _FILE_OFFSET_BITS as 64 on all platforms.
	add_definitions(-D_FILE_OFFSET_BITS=64)

[jkotas]

Perhaps we just need to set _TIME_BITS=64 globally next to

@am11 Would you be interested in submitting a PR with this fix?