Skip to content
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

WASI interface for accessing timezone offsets? #467

Open
ColinEberhardt opened this issue Jan 28, 2022 · 2 comments
Open

WASI interface for accessing timezone offsets? #467

ColinEberhardt opened this issue Jan 28, 2022 · 2 comments
Labels
feature-request Requests for new WASI APIs

Comments

@ColinEberhardt
Copy link

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?

@tschneidereit
Copy link
Member

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 wasi-tz in environments that don't already provide the required information.

@ColinEberhardt
Copy link
Author

Thanks @tschneidereit - sounds like it might be worth moving this forwards as a proposal?

Good point about virtualizing via a wasm component.

@sunfishcode sunfishcode added the feature-request Requests for new WASI APIs label Jul 19, 2022
dicej added a commit to dicej/teavm that referenced this issue Aug 9, 2022
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 <joel.dice@fermyon.com>
dicej added a commit to fermyon/teavm-wasi that referenced this issue Sep 2, 2022
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 <joel.dice@fermyon.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Requests for new WASI APIs
Projects
None yet
Development

No branches or pull requests

3 participants