Time zone support #25
Comments
|
Does this use case need access to the timezone database, as is being discussed in WebAssembly/WASI#25, or would it be enough to just return the UTC offset? |
|
In my use case I just need the offset. In case it helps, I'm trying to patch the rust crate |
|
For completeness, some other prior related issues: |
|
I looked more closely at the implementation of |
|
On Kotlin side, I am leveraging https://github.com/Kotlin/kotlinx-datetime multi-platform library, which seems to require access to the timezone database, see the platform specific functions here. |
Add a small timezone API that returns the UTC offset, timezone name, and daylight saving time status for a given `datetime` timestamp. This is not a full timezone database API. It's designed so that implementations that don't wish to do anything with timezones can just support a single "UTC" time zone, which can be easily implemented. It's also not a time formatting or locale API. It doesn't say how to format a human-readable timestamp; it just provides the information that would typically be formatted into a human-readable timestamp. This API expects a `timezone` handle argument will be added to the command entrypoint function, providing programs with a `timezone` to provide timezone information about wall-clock timestamps. Fixes WebAssembly#25.
* Add a timezone API. Add a small timezone API that returns the UTC offset, timezone name, and daylight saving time status for a given `datetime` timestamp. This is not a full timezone database API. It's designed so that implementations that don't wish to do anything with timezones can just support a single "UTC" time zone, which can be easily implemented. It's also not a time formatting or locale API. It doesn't say how to format a human-readable timestamp; it just provides the information that would typically be formatted into a human-readable timestamp. This API expects a `timezone` handle argument will be added to the command entrypoint function, providing programs with a `timezone` to provide timezone information about wall-clock timestamps. Fixes #25.
I'm working on a project in a WASI context that uses time in local time zones. I see how the API in this proposal would support getting the current time in the UTC time zone, but not in the user's local time zone.
What do you think about adding a new resource that lets the WASI guest fetch the local time zone (e.g. as seconds offset from UTC)? Since the local time zone could be used to fingerprint a user, it makes sense to me to add a resource as a new capability to control access to this.
The text was updated successfully, but these errors were encountered: