gmtime is still 32 bit (wrapping to 1900 after 2038)

[mmarczell-graphisoft]

Parts of the time.h / ctime API still don't support 64 bit time, as demonstrated by the following snippet:

#include <iostream>
#include <ctime>

int main () {
	struct tm tm;
	memset (&tm, 0, sizeof (tm));
	tm.tm_mon = 1;
	tm.tm_mday = 2;
	tm.tm_hour = 3;
	tm.tm_min = 4;
	tm.tm_sec = 5;
	tm.tm_isdst = -1;
	tm.tm_zone = "UTC";

	for (int year :  { 2035, 2040 }) {
		tm.tm_year = year - 1900;
		
		time_t timeVal = timegm (&tm);

		struct tm* ptm = gmtime (&timeVal);
		if (ptm) {
			std::cout << ptm->tm_year + 1900 << " should equal " << year << std::endl;
		}
	}	
}

It prints

2035 should equal 2035
1903 should equal 2040

Related:
#17393, #17401, #17471

I understand the reasons behind this with JS Number being less than 64 bit, but I still think it's a bug.

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.34 (57b21b8fdcbe3ebb523178b79465254668eab408)
clang version 17.0.0 (https://github.com/llvm/llvm-project a031f72187ce495b9faa4ccf99b1e901a3872f4b)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /Volumes/SSD/git/emsdk/upstream/bin

But I believe the bug is present in latest too.

[sbc100]

JS Number can hold up to 53bits, so that should be plenty.

Any idea where the remaining bug lies.. it not in the definition of time_t..

[sbc100]

I found the source of the problem:

emscripten/system/lib/libc/emscripten_internal.h

Lines 38 to 43 in eab65a0

	// Declare these functions `int` rather than time_t to avoid int64 at the wasm
	// boundary (avoids 64-bit complexity at the boundary when WASM_BIGINT is
	// missing).
	// TODO(sbc): Covert back to `time_t` before 2038 ...
	int _timegm_js(struct tm* tm);
	int _mktime_js(struct tm* tm);

I wonder if this is actually urgent to fix? i.e. does real world code care about this today? Fixing would likely involve a slight code size bump for all users.

[sbc100]

The reason I ask is that in a few months when we have wasm-bigint enabled by default this should be trivial to fix.

[kripken]

Good find. Sgtm to wait for WASM_BIGINT by default - that will surely happen before 2038! 🤣

[sbc100]

Actually it looks like we can fix without regressing code size for most programs..