Ah, thanks! Sorry, I'd missed that, and ran into some trouble with the issue of passing a ref. But all looks like it works now.
Anyway, I uncovered something rather interesting here. The approach I took was:
let systime = match SystemTime::try_from(timestamp) {
Ok(systime) => systime,
Err(duration) => UNIX_EPOCH - duration
}
... but this uncovers something interesting. Suppose that we specify a negative Timestamp:
let ts = Timestamp { seconds: -20, nanos: 999 };
let systime = match SystemTime::try_from(timestamp) {
Ok(systime) => systime,
Err(duration) => UNIX_EPOCH - duration
}
then we trigger the Err branch, and get out SystemTime { tv_sec: -21, tv_nsec: 999999001 }.
In other words, Timestamp treats the nanos part as effectively decimal places for the seconds value (effectively sharing its sign), whereas SystemTime treats its tv_sec and tv_nsec part as separate additions to the time epoch.
What's particularly interesting is that even though Timestamp can theoretically represent values from 0001-01-01T00:00:00Z to 9999-12-31T23:59:59.999999999Z, it seems to panic when converting from a SystemTime before the start of the time epoch:
let input_systime = UNIX_EPOCH - Duration::from_secs(20);
println!("input SystemTime: {:?}", input_systime);
let ts = Timestamp::from(input_systime);
println!("Timestamp: {:?}", ts);
... generates input_systime OK but panics when converting to Timestamp:
input SystemTime: SystemTime { tv_sec: -20, tv_nsec: 0 }
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(20s)'
I'm a little bit surprised both at the subtly different expected data contents of Timestamp and SystemTime, and at the failure of conversion. I'll try to submit an issue to prost_types if I get a moment.