Re: host unresponsive when setting time very far in the future

From: Jan Schaumann <jschauma_at_netmeister.org>
Date: Mon, 17 Oct 2022 18:05:05 UTC
Warner Losh <imp@bsdimp.com> wrote:

> We do know that if the year (tm_year) overflows an int (32-bit signed),
> we'll
> have problems. It would be approximately year 2,147,483,648 (since I think
> the limitation is signed, not unsigned, but if unsigned it's 4294967296
> instead).

Right, though since tm_year is defined as "year ­
1900", I'd expect to be able to reach 12/31 23:59:59
in 2,147,485,547, as on e.g., NetBSD and Linux:

 netbsd$ date -r 67768036191676799
 Wed Dec 31 23:59:59 UTC 2147485547

 linux$ date --date '@67768036191676799'
 Wed Dec 31 11:59:59 PM UTC 2147485547

But FreeBSD:
 freebsd$ date -r 67768036191676799
 date: invalid time
 freebsd$ date -r 67767976233532799
 Tue Dec 31 23:59:59 UTC 2147483647

Kinda unclear to me how FreeBSD ended up with a
tm_year value that's not 1900 based here?

> Anything beyond that we know definitely won't work. Why we fall short
> and "only" make it to year 1.561,694,399, I don't know the root
> cause of. It's not even a nice, round multiple of the above...

Regardless of the root cause, though, I think
something somewhere should return EINVAL before the
system freaks out. :-)

-Jan