ulid-rs icon indicating copy to clipboard operation
ulid-rs copied to clipboard

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

Open lpotthast opened this issue 2 years ago • 2 comments

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

lpotthast avatar Jul 15 '22 12:07 lpotthast

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

dylanhart avatar Aug 02 '22 04:08 dylanhart

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

lpotthast avatar Sep 12 '22 12:09 lpotthast

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

dylanhart avatar Jan 12 '23 03:01 dylanhart

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

lpotthast avatar Jan 16 '23 11:01 lpotthast

@dylanhart WDYT about upstreaming https://github.com/dylanhart/ulid-rs/compare/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 avatar Jan 20 '24 07:01 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!

Ekleog avatar Jan 21 '24 18:01 Ekleog

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

jakubadamw avatar Jan 31 '24 09:01 jakubadamw

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.

dylanhart avatar Jan 31 '24 20:01 dylanhart

@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 avatar Jan 31 '24 21:01 jakubadamw

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

jakubadamw avatar Jan 31 '24 22:01 jakubadamw

Awesome, thank you! :D

Ekleog avatar Feb 02 '24 15:02 Ekleog