Inspired by comment in this issue: octokit/webhooks.net#591 (comment)

If code using DateTimeOffset.FromUnixTimeSeconds(long) passes a variable of type int to it, that value will be implicitly converted to a long and in most cases today will work just fine. However, that leaves the code susceptible to Year-2038 issues when a date is too far in the future to be represented as a 32-bit integer.

For literals or constants, this is likely fine, as maybe it's a hard-coded reference to a fixed point in time, but for code referencing a variable/property/etc. of type int, this might be a looming bug (e.g. deserializing a value from JSON to a POCO) that hints at a type mismatch that will fail at some point in the future.

An example of this is as referenced in the issue above:

private static DateTimeOffset HandleNumber(Utf8JsonReader reader)
    => DateTimeOffset.FromUnixTimeSeconds(reader.GetInt32());

This bug could have been avoided with an analyzer that warned of the potential for overflow, which could have lead to the original author instead writing the following:

private static DateTimeOffset HandleNumber(Utf8JsonReader reader)
    => DateTimeOffset.FromUnixTimeSeconds(reader.GetInt64());