I know it’s OS dependent thing, but I feel like many people here could help me to understand it better.
The thing is that calendar:universal_time_to_system_time({{1902,01,01}, {0,0,0}}) returns a valid result, but calendar:universal_time_to_system_time({{1901,12,31}, {23, 59,59}} (and all universal times below that) throws badarg with not a valid universal time.
Why is year 1902 a limit? Can that be configured somehow?
$ erl
Erlang/OTP 28 [erts-16.0.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1]
Eshell V16.0.2 (press Ctrl+G to abort, type help(). for help)
1> calendar:universal_time_to_system_time({{1901,12,31}, {23, 59,59}}).
-2145916801
So this is a question for your “OS”.
Sorry, but I made a mistake in the original post. It’s not universal_time_to_system_time, but universal_time_to_local_time…
What may be the clue is that if calendar:universal_time_to_system_time({{1902,01,01}, {0,0,0}}) returns -2145916800 which is just slightly below minimal signed int32…
Turns out this is not OS dependent.
From the OTP sourcecode:
/* This is the earliest year we are sure to be able to handle
on all platforms w/o problems */
#define BASEYEAR 1902
if (!(IN_RANGE(BASEYEAR, *year, INT_MAX - 1) &&
That’s interesting, seems like 32 bits when converting to seconds is not a limit because year can e.g. be 10000 which is out out of 32 bits when converted to seconds.
This was introduced 14 years ago with no information on why exactly that year is chosen…