I'm trying to convert an untrusted user-supplied UNIX timestamp to a SystemTime. The standard way to do this described in the documentation seems to be adding a Duration created from the timestamp to SystemTime::UNIX_EPOCH. The Problem with this is that there could be overflows that I can't handle well that way. A workaround would be to define a maximum for the timestamp, but since the SystemTime struct is opaque and makes no promises regarding it's range that will always just be a heuristic that works for most practical systems. So for me as a library author who has to work with untrusted user input this API isn't really usable without giving a bunch of caveats to my downstream users.
The obvious solution to this would be to add a checked_add function to SystemTime. Is such a proposal on it's way or was it rejected and I'm missing something?
For a relatively small libs change (especially one relatively straightforward), just make a PR explaining the addition and why it's desired. It can FCP inline there (and will for sure during stabilization or dropping if the PR is merged).
My ManuallyDrop::take PR can serve as an example here. (You don't need to file a tracking issue immediately, just before it's merged.)
It won't even need a tracking issue. Implementing a stable trait for a stable type is also stable right away. (After riding the nightly-beta-stable release train, of course.)