std::time::SystemTime misses a checked_add function


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?

I don't think you're missing anything - it seems like a straightforward thing we should add!

I don't know too much about the rust std-lib development process, would this need a RFC or just a PR?

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.)

1 Like

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.)

This would be an inherent method, not a trait implementation, but yes, a direct PR is fine!

Oh, I got my wires crossed -- CheckedAdd is in num-traits.