On Tue Feb 6 11:11:11 2024 +0000, Piotr Caban wrote:
Shouldn't we update the _MAX__TIME64_T value instead? It looks like the ranges could be also updated in other functions that use this (I didn't check if exact values match between _gmtime64, _wctime64 and _localtime64). Taking in account that the values change between dll version we probably don't have to support exactly the same range as native. A quick test shows that _MAX__TIME64_T is not correct for _wctime64 in ucrtbase.
I checked with _localtime64_s() on ucrtbase and it doesn't allow negative values. Maximum time is current _MAX__TIME64_T + 1555200 (vs 1605600 for _gmtime64_s), which is 14 hours difference and doesn't match neither negative offset of _gmtime64_s nor my local time difference to GMT (either side).
So do you suggest updating _MAX__TIME64_T constant universally, for all the functions and CRT versions? Maybe we should keep old msvcrt result at least, and then drop test for CRT140 and follow up to date ucrtbase _gmtime64_s value?