Description
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());