v0.6 WASM runtime error: 'time not implemented on this platform'

[lpotthast]

When using v0.5 everything runs fine in my Yew-WASM-applications, targeting wasm32-unknown-unknown and the web. So the chrono implementation works.

When using v0.6 (with default features), creating a Ulid panics with 'time not implemented on this platform', as the time crate seems to call std::time functions.

Should I use a different set of features? I were not able to find anything to control this. Neither here nor in the time crate..

[dylanhart]

Please try v1.0. If that still doesn't work, sticking with v0.5 should be fine as there are no known issues there.

[lpotthast]

1.0 does not work unfortunately.

time is guarded by the 'std' feature.

This means that I have to disable std in order to run on wasm.
But I do need the serde feature, which relies on std String, leading to compilation errors..

[dylanhart]

The grafbase fork looks like it may have a fix: https://github.com/grafbase/ulid-rs/tree/wasm32-unknown-unknown-js-sys-time

[lpotthast]

Looks promising. It would be great to see these commits upstreamed to this crate!

[Ekleog]

@dylanhart WDYT about upstreaming master...grafbase:ulid-rs:wasm32-unknown-unknown-js-sys-time ? The changes seem simple enough, and could help quite nicely with using this crate on wasm32

[Ekleog]

Actually better than this: Using chrono::Utc::now() to generate the datetime would actually make ULID timestamps be UTC values, rather than localtime values. Currently, two machines in two different timezones generating ULIDs would not actually have them lexicographically sortable. Plus, chrono has a proper implementation on wasm32, so it would also solve this problem.

This would better match the intent of the spec at least (though it does not seem to actually enforce UTC), as this way the ULIDs would actually be universally lexicographically sortable.

Edit: I now notice how stupid I am to have forgotten that SystemTime.duration_since(UNIX_EPOCH) already returns UTC time even on windows machines. Sorry for the noise!

[jakubadamw]

@lpotthast @dylanhart @Ekleog I opened a PR that does this a bit nicer than what we did in the branch that you had found. 🙂

[dylanhart]

WASM users, is there a good method of checking WASM support? I'd like to add something to the presubmit CI to check that support doesn't break again in the future.

[jakubadamw]

@dylanhart a test compiled to wasm32-wasi and run with https://github.com/bytecodealliance/wasmtime should be short and simple. I can do it tomorrow if you could wait. 🙂

[jakubadamw]

@dylanhart actually, I managed to do it now, these days it's simpler than I thought. Here's the PR.

[Ekleog]

Awesome, thank you! :D