-
Notifications
You must be signed in to change notification settings - Fork 280
WASI interface for accessing timezone offsets? #467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think this would make a lot of sense to do, yes. I also like that it's readily virtualizable via a wasm component containing the required data, so by including that one can run content depending |
Thanks @tschneidereit - sounds like it might be worth moving this forwards as a proposal? Good point about virtualizing via a wasm component. |
Previously, TeaVM used imported functions for timezone resolution, char case conversion, and floating point tests. Since WASI doesn't support any of those things, we implement them in Java as best we can. Floating point tests are easy; timezone resolution will have to wait for WebAssembly/WASI#467 (we hard-code UTC for now); case conversion can be done entirely in Java, although I've only handled ASCII characters in this commit. Signed-off-by: Joel Dice <[email protected]>
Previously, TeaVM used imported functions for timezone resolution, char case conversion, and floating point tests. Since WASI doesn't support any of those things, we implement them in Java as best we can. Floating point tests are easy; timezone resolution will have to wait for WebAssembly/WASI#467 (we hard-code UTC for now); case conversion can be done entirely in Java, although I've only handled ASCII characters in this commit. Signed-off-by: Joel Dice <[email protected]>
This came up again here, for reference. |
A little while back I started work on implementing the new TC39 Temporal standard in AssemblyScript. The non-timezone aware parts of this API were relatively easy to implement (see assemblyscript-temporal), however, the more interesting timezone-aware parts of the API are more challenging!
My initial attempt has been to store the IANA timezone database a part of the module, but this results in a sizeable binary, and decoding the IANA timezone files isn't much fun (see assemblyscript-temporal-tz).
Most environments where WebAssembly will be run will already have this timezone information available as part of the OS, so rather than include it within the wasm module, it makes sense access this information from the host, via WASI (calling it, for example, wasi-tz)
The WASI information that supports this would be very simple, the Temporal API can be implemented based on a single method
offsetForTimezone(tz: string, epochMillis: i64): i32
. Although wasi-tz would probably need methods that allow you to enumerate supported timezones also.What does this community think of this idea? Is there value in wasi-tz?
The text was updated successfully, but these errors were encountered: