Closed zecakeh closed 2 months ago
I don't want to add such a dependency on all crates to support std::time
on WASM... I strongly feel it should be fixed in libstd
, probably requiring something like wasm32-unknown-browser
or similar.
In that case another option could be to have APIs to work without those types, but with raw values. Like represent a date as a u64
timestamp, or a delay as u64
seconds.
It's also possible for another crate to provide typed headers like that. This crate provides a trait and common impls, but anyone can implement any header, it doesn't conflict.
Alright, closing this then, if it's out of scope.
Currently, the headers that represent a duration or date use
std::time::Duration
andstd::time::SystemTime
. The methods of these types panic when using thewasm32-unknown-unknown
target.This can be worked around by using a crate like web_time, that uses
std::time
with all targets butwasm32-unknown-unknown
, where it uses Web APIs instead.That also means that there will be an incompatibility with the httpdate crate that is used currently, as it uses
std::time
too. It could either be changed to use web_time too, or we could change the dependency to use date_header, that returns a timestamp instead.Would a PR in that direction be accepted?