Closed j-white closed 10 months ago
On non-WASM, it should be the same type. On WASM without WASI, you shouldn't be able to instantiate std::time::SystemTime
anyways.
I think the following would suffice:
fn to_std_systemtime(time: web_time::SystemTime) -> std::time::SystemTime {
let duration = time.duration_since(web_time::SystemTime::UNIX_EPOCH).unwrap();
std::time::SystemTime::UNIX_EPOCH + duration
}
The problem is that the library you are trying to be compatible with could be using std::time::SystemTime::now()
internally, which would panic during runtime. So either way I would encourage you to check with the library if they could depend on web-time
if it makes sense.
In any case, I think adding a conversion behind a trait doesn't hurt, though I will document that this might just be a footgun.
On that note, I will also transition to using Duration
internally on SystemTime
, right now it is using i64
.
The original reason was that according to ECMA Date.now()
can actually return negative numbers, but that isn't really practically possible in our use-case here. I'm sure there are some weird JS environments out there that might support something like this, but we are targeting Web and browsers, which shouldn't be supporting that.
Awesome - thanks for the simplified snippet and feedback!
I still plan on adding the conversion!
I ran into a case where I needed to cast an instance of
web_time::SystemTime
back to astd::time::SystemTime
since another library's struct explicitly required that type.I came up with this function as a bandaid:
Is there a nicer way to do this? Would it make sense to include such a function in the lib?
Thanks!