wasmtime / PR #6899 Add timezone host functions. · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #6899 Add timezone host functions.

Wasmtime GitHub notifications bot (Aug 24 2023 at 13:38):

cdmurph32 opened PR #6899 from cdmurph32:timezone to bytecodealliance:main:

Issue:
https://github.com/bytecodealliance/wasmtime/issues/4274

WASI Clocks proposal:
https://github.com/WebAssembly/wasi-clocks/pull/48

Relate cap-std PR:
https://github.com/bytecodealliance/cap-std/pull/327

Wasmtime GitHub notifications bot (Aug 26 2023 at 00:47):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Aug 28 2023 at 20:10):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Aug 28 2023 at 20:17):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Mar 08 2024 at 20:28):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Mar 08 2024 at 20:46):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Mar 09 2024 at 12:35):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Mar 09 2024 at 16:17):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Mar 09 2024 at 17:52):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Mar 11 2024 at 12:56):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Jun 17 2024 at 14:27):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Jun 29 2024 at 21:54):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Jul 02 2024 at 14:33):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Jul 09 2024 at 00:26):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Jul 09 2024 at 00:34):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Aug 22 2025 at 22:54):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Aug 24 2025 at 00:12):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Aug 25 2025 at 18:30):

cdmurph32 has marked PR #6899 as ready for review.

Wasmtime GitHub notifications bot (Aug 25 2025 at 18:30):

cdmurph32 requested wasmtime-wasi-reviewers for a review on PR #6899.

Wasmtime GitHub notifications bot (Aug 25 2025 at 18:30):

cdmurph32 requested alexcrichton for a review on PR #6899.

Wasmtime GitHub notifications bot (Aug 25 2025 at 18:30):

cdmurph32 requested wasmtime-default-reviewers for a review on PR #6899.

Wasmtime GitHub notifications bot (Aug 25 2025 at 18:30):

cdmurph32 requested wasmtime-core-reviewers for a review on PR #6899.

Wasmtime GitHub notifications bot (Aug 25 2025 at 20:48):

alexcrichton submitted PR review:

I'm not expert on timezones or clocks so I can't review the APIs as-is, but despite that I've still got a few questions about this:

Does it still make sense to use chrono and chrono-tz? Since this PR was opened I think jiff was released which might be more modern.

Does chrono or chrono-tz have any sort of system dependency on something like a timezone database? If so, are there any consequences to that? If not should it? Or will we need to update frequently?

What's the build/size impact of including chrono and chrono-tz? Adding 10M to the executable? 10K?

We're generally pretty conservative with the defaults of a WASI program, so it might make more sense to default to UTC instead of the local timezone maybe?

This PR has been pretty inactive for ~2 years and now mergable without much discussion here. That's understandable though if the discussion happened upstream. Do you have links and/or confirmation for others that it's suitable to add this at this time? (or is there no such body that makes sense to confirm this decision?)

Wasmtime GitHub notifications bot (Aug 25 2025 at 20:48):

alexcrichton created PR review comment:

Would it perhaps make sense to frontload this linear search in the Timezone::new constructor?

Also, would it also make sense to provide a Timezone::new_utc() constructor?

Wasmtime GitHub notifications bot (Aug 26 2025 at 13:33):

cdmurph32 commented on PR #6899:

This PR has been delayed for the past 2 years by the following discussions:
https://github.com/WebAssembly/wasi-clocks/issues/69
https://github.com/WebAssembly/wasi-clocks/pull/79

Recently it was decided that the result of these discussions will land in 0.3. Therefore this PR can move ahead for 0.2. The 0.3 wit files will be different for all 3 interfaces (wall-clock, monotonic-clock, timezone).

Wasmtime releases should use the latest version of whichever crate is providing the IANA timezone database, just as any other software would. There are updates every few, but they are typically driven by geopolitics and are not on a predictable cadence.

I will try out jiff as a replacement and report the difference in build size.

Wasmtime GitHub notifications bot (Aug 26 2025 at 14:26):

alexcrichton commented on PR #6899:

Forgive me if these are naive questions, but I haven't been following this proposal closely in the interim years. Do you have a link to a decision somewhere of "let's ship unstable APIs in 0.2"? I'm a bit surprised by that if the APIs are going to be entirely different in 0.3 so I'm curious to read up on the rationale.

just as any other software would

Do you have a sense for how other software does? For example does most software bundle the database? Use an external database? (I'm new to timezones in this regard). Basically is Wasmtime doing the "standard thing" here? Or do we know if chrono is non-standard in any way?

I will try out jiff as a replacement and report the difference in build size.

To clarify I'm mostly just curious if it was considered. I do not know how to evaluate tradeoffs so I'm relying on expert advice in this area. I, myself, am not equipped to render judgment on a chrono-vs-jiff decision so what I'm trying to do is ask leading questions. My hope is to read the analysis of someone else's judgment and see if I have further questions or whether we can link to that in the future for example.

Wasmtime GitHub notifications bot (Aug 27 2025 at 10:04):

rvolosatovs commented on PR #6899:

Looks like https://docs.rs/jiff/latest/jiff/_documentation/design/index.html#chrono and https://docs.rs/jiff/latest/jiff/_documentation/comparison/index.html#chrono-v0438 give a pretty good overview of differences between jiff and chrono.

From my perspective, since jiff:

reads the timezone database from the OS by default on supported systems (which IMO is the right thing to do)

has fully standard-compliant timezone handling implemented

I'd prefer using jiff instead. If we really wanted to, we could even expose an option to force embedding of the database on all systems as a compile-time flag for advanced embedding use cases.

Since the interface is fairly small and functionality would be largely reused for e.g. p3 or any potential p2 timezone interface changes (https://github.com/WebAssembly/wasi-clocks/pull/71) I think it's fine to land this, as the maintenance cost we'd incur would be minor even if/when the timezone interface would change

Wasmtime GitHub notifications bot (Aug 27 2025 at 10:14):

rvolosatovs submitted PR review.

Wasmtime GitHub notifications bot (Aug 27 2025 at 10:14):

rvolosatovs created PR review comment:

I feel like this interface would have been useful if embedders were able to provide an arbitrary timezone to use with UTC default.

There are many ways to do that, but perhaps we could:

store jiff::tz::TimeZone https://docs.rs/jiff/latest/jiff/tz/struct.TimeZone.html in the struct

provide TryFrom<cap_time_ext::Timezone> for Timezone

provide From<jiff::tz::Timezone> for Timezone

If we had that, we could have a Default implemented for Timezone, which would default to UTC.

We could then:

rename new to something like new_host and make it fallible

add new_utc, which acts the same as Default

maybe implement FromStr for Timezone in terms of https://docs.rs/jiff/latest/jiff/tz/struct.TimeZone.html#method.get ?

Wasmtime GitHub notifications bot (Aug 27 2025 at 15:14):

cdmurph32 submitted PR review.

Wasmtime GitHub notifications bot (Aug 27 2025 at 15:14):

cdmurph32 created PR review comment:

Maybe we should replace iana_time_zone with jiff in cap-std-ext?
https://github.com/bytecodealliance/cap-std/blob/main/cap-time-ext/src/timezone.rs

Wasmtime GitHub notifications bot (Aug 27 2025 at 19:57):

cdmurph32 submitted PR review.

Wasmtime GitHub notifications bot (Aug 27 2025 at 19:57):

cdmurph32 created PR review comment:

    fn timezone_from_duration(&self, datetime: Duration) -> Option<TimezoneDisplay> {
        let tz = self.timezone.timezone().ok()?;
        let timestamp = Timestamp::from_second(datetime.as_secs() as i64).ok()?;
        let localtime = tz.to_offset_info(timestamp);
        let utc_offset = localtime.offset().seconds();
        let name = tz.iana_name().unwrap_or("UTC").to_string();
        let in_daylight_saving_time = jiff::tz::Dst::Yes == localtime.dst();
        Some(TimezoneDisplay {
            utc_offset,
            name,
            in_daylight_saving_time,
        })
    }
If I replace iana_time_zone with jiff in cap-std-ext we could have something like this. Jiff automatically returns UTC if the timezone cannot be determined. Does this look better?
Pros: No more linear search
Cons: cap-std-ext::Timezone now returns a giff::Timezone instead of a string. Not really std behavior.
If that Con is a deal breaker, I could keep the return type a string and convert the string back into a jiff timezone

Wasmtime GitHub notifications bot (Aug 27 2025 at 20:17):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Aug 27 2025 at 20:17):

alexcrichton created PR review comment:

For me it's not necessarily a requirement to change cap-std bits, it's fine to use jiff directly here in Wasmtime

Wasmtime GitHub notifications bot (Aug 27 2025 at 21:42):

pchickey submitted PR review.

Wasmtime GitHub notifications bot (Aug 27 2025 at 21:42):

pchickey created PR review comment:

I'd prefer to wasmtime-wasi jiff directly instead of going through cap-std-ext, I don't think the indirection through that additional crate is really getting us much in this case. The user can provide.a jiff::Timezone to the WasiCtxBuilder and if they don't it should default to UTC. We can then have a wasmtime-cli flag for setting a time zone, or "auto" which allows jiff to make its best effort to figure one out.

Wasmtime GitHub notifications bot (Aug 27 2025 at 22:06):

rvolosatovs edited PR review comment.

Wasmtime GitHub notifications bot (Aug 28 2025 at 15:45):

cdmurph32 created PR review comment:

Do we still need the ambient authority marker, or can we get rid of timezone in cap-std-ext altogether?
Should we have this?
pub struct Timezone {
    timezone: cap_time_ext::Timezone,
    jiff_timezone: JiffTimeZone,
}
or this?
pub struct Timezone {
    timezone: JiffTimeZone,
}

Wasmtime GitHub notifications bot (Aug 28 2025 at 15:45):

cdmurph32 submitted PR review.

Wasmtime GitHub notifications bot (Aug 28 2025 at 15:45):

cdmurph32 edited PR review comment.

Wasmtime GitHub notifications bot (Aug 28 2025 at 16:24):

rvolosatovs created PR review comment:

I'd expect to see something like:
pub struct Timezone {
    // The underlying system timezone.
    timezone: jiff::tz::Timezone,
}

impl Default for Timezone {
    fn default() -> Self {
        Self::from(jiff::tz::Timezone::UTC)
    }
}

impl From<jiff::tz::Timezone> for Timezone {
   fn from(timezone: jiff::tz::Timezone) -> Self {
       Self {
          timezone,
       }
   }
}
Personally, I am wary of exposing third-party library dependencies in public API, especially pre-1.0, since that could cause hard to debug issues downstream if/when jiff version does not match for users. That's why I'm proposing FromStr implemntation via get, such that users can do let tz: Timezone = "Europe/Amsterdam"::parse()?

Wasmtime GitHub notifications bot (Aug 28 2025 at 16:24):

rvolosatovs submitted PR review.

Wasmtime GitHub notifications bot (Aug 28 2025 at 16:24):

rvolosatovs edited PR review comment.

Wasmtime GitHub notifications bot (Aug 28 2025 at 16:26):

rvolosatovs edited PR review comment.

Wasmtime GitHub notifications bot (Aug 28 2025 at 16:30):

rvolosatovs edited PR review comment.

Wasmtime GitHub notifications bot (Aug 29 2025 at 12:52):

cdmurph32 submitted PR review.

Wasmtime GitHub notifications bot (Aug 29 2025 at 12:52):

cdmurph32 created PR review comment:

Thanks. That answers my question. We can get rid of the ambient authority.

Wasmtime GitHub notifications bot (Aug 30 2025 at 13:51):

cdmurph32 updated PR #6899.

Wasmtime GitHub notifications bot (Aug 30 2025 at 14:05):

cdmurph32 commented on PR #6899:

Forgive me if these are naive questions, but I haven't been following this proposal closely in the interim years. Do you have a link to a decision somewhere of "let's ship unstable APIs in 0.2"? I'm a bit surprised by that if the APIs are going to be entirely different in 0.3 so I'm curious to read up on the rationale.

just as any other software would

Do you have a sense for how other software does? For example does most software bundle the database? Use an external database? (I'm new to timezones in this regard). Basically is Wasmtime doing the "standard thing" here? Or do we know if chrono is non-standard in any way?

No apology necessary. Other than this WASI and wasmtime work, I have no particular experience with timezones or clocks either.

Yes, both chrono and jiff come with their own timezone databases. This is the standard as far as I can tell. If a new timezone is created after the database in use and the system returns that new timezone, the jiff::tz::Timezone will be "TimeZone::unknown()", and as my PR is currently written, the timezone provided by wasmtime will fallback to UTC.

I will try out jiff as a replacement and report the difference in build size.

To clarify I'm mostly just curious if it was considered. I do not know how to evaluate tradeoffs so I'm relying on expert advice in this area. I, myself, am not equipped to render judgment on a chrono-vs-jiff decision so what I'm trying to do is ask leading questions. My hope is to read the analysis of someone else's judgment and see if I have further questions or whether we can link to that in the future for example.

As @rvolosatovs mentioned, jiff appears to be the better fit. It appears to add ~ 1MB to the wasmtime binary as opposed to 2 MB with chrono.

Wasmtime GitHub notifications bot (Aug 30 2025 at 14:17):

cdmurph32 edited a comment on PR #6899:

Forgive me if these are naive questions, but I haven't been following this proposal closely in the interim years. Do you have a link to a decision somewhere of "let's ship unstable APIs in 0.2"? I'm a bit surprised by that if the APIs are going to be entirely different in 0.3 so I'm curious to read up on the rationale.

No apology necessary. Other than this WASI and wasmtime work, I have no particular experience with timezones or clocks either.
On the one hand, this work is behind the wasi option clocks-timezone. This options are also used to gate the unstable features network-error-code and cli-with-exit-code.

On the other hand, the proposed changes for clocks in 0.3 rename monotonic and wall-clock. I'm not sure exactly how they would work with the code as presently constructed. Timezone will probably also change.

just as any other software would

Do you have a sense for how other software does? For example does most software bundle the database? Use an external database? (I'm new to timezones in this regard). Basically is Wasmtime doing the "standard thing" here? Or do we know if chrono is non-standard in any way?

Yes, both chrono and jiff come with their own timezone databases. This is the standard as far as I can tell. If a new timezone is created after the database in use and the system returns that new timezone, the jiff::tz::Timezone will be "TimeZone::unknown()", and as my PR is currently written, the timezone provided by wasmtime will fallback to UTC.

I will try out jiff as a replacement and report the difference in build size.

To clarify I'm mostly just curious if it was considered. I do not know how to evaluate tradeoffs so I'm relying on expert advice in this area. I, myself, am not equipped to render judgment on a chrono-vs-jiff decision so what I'm trying to do is ask leading questions. My hope is to read the analysis of someone else's judgment and see if I have further questions or whether we can link to that in the future for example.

As @rvolosatovs mentioned, jiff appears to be the better fit. It appears to add ~ 1MB to the wasmtime binary as opposed to 2 MB with chrono.

Wasmtime GitHub notifications bot (Aug 30 2025 at 14:17):

cdmurph32 edited a comment on PR #6899:

@alexcrichton

Forgive me if these are naive questions, but I haven't been following this proposal closely in the interim years. Do you have a link to a decision somewhere of "let's ship unstable APIs in 0.2"? I'm a bit surprised by that if the APIs are going to be entirely different in 0.3 so I'm curious to read up on the rationale.

No apology necessary. Other than this WASI and wasmtime work, I have no particular experience with timezones or clocks either.
On the one hand, this work is behind the wasi option clocks-timezone. This options are also used to gate the unstable features network-error-code and cli-with-exit-code.

On the other hand, the proposed changes for clocks in 0.3 rename monotonic and wall-clock. I'm not sure exactly how they would work with the code as presently constructed. Timezone will probably also change.

just as any other software would

Do you have a sense for how other software does? For example does most software bundle the database? Use an external database? (I'm new to timezones in this regard). Basically is Wasmtime doing the "standard thing" here? Or do we know if chrono is non-standard in any way?

Yes, both chrono and jiff come with their own timezone databases. This is the standard as far as I can tell. If a new timezone is created after the database in use and the system returns that new timezone, the jiff::tz::Timezone will be "TimeZone::unknown()", and as my PR is currently written, the timezone provided by wasmtime will fallback to UTC.

I will try out jiff as a replacement and report the difference in build size.

To clarify I'm mostly just curious if it was considered. I do not know how to evaluate tradeoffs so I'm relying on expert advice in this area. I, myself, am not equipped to render judgment on a chrono-vs-jiff decision so what I'm trying to do is ask leading questions. My hope is to read the analysis of someone else's judgment and see if I have further questions or whether we can link to that in the future for example.

As @rvolosatovs mentioned, jiff appears to be the better fit. It appears to add ~ 1MB to the wasmtime binary as opposed to 2 MB with chrono.

Wasmtime GitHub notifications bot (Aug 30 2025 at 14:32):

cdmurph32 submitted PR review.

Wasmtime GitHub notifications bot (Aug 30 2025 at 14:32):

cdmurph32 created PR review comment:

I'd prefer to wasmtime-wasi jiff directly instead of going through cap-std-ext, I don't think the indirection through that additional crate is really getting us much in this case. The user can provide.a jiff::Timezone to the WasiCtxBuilder and if they don't it should default to UTC. We can then have a wasmtime-cli flag for setting a time zone, or "auto" which allows jiff to make its best effort to figure one out.

Yes. Jiff seems to be the way to go. I've updated the PR to reflect that.

I think allowing the user to override the system timezone is reasonable, especially for testing purposes, but I don't see why we would want to default to UTC if that timezone is not provided. Reporting the correct timezone would be the expected behavior for most applications and would be consistent with native code. For edge compute applications, I would imagine the automatic reporting of the correct timezone is a table stakes expectation.

Wasmtime GitHub notifications bot (Sep 03 2025 at 18:04):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Sep 03 2025 at 18:04):

alexcrichton created PR review comment:

Personally I'd agree with @rvolosatovs that the default time zone should be UTC. I don't doubt that many embedders will want to change this but Wasmtime's default stance has been one to sandbox everything and picking a deterministic default feels more sand-box-y to me than inferring based on the host system. For embedders that want to use the native time zone though I'd want to make sure we can easily enable that with a single call on WasiCtxBuilder, for example.

Wasmtime GitHub notifications bot (Sep 03 2025 at 18:05):

alexcrichton commented on PR #6899:

@cdmurph32 do you have a link to the discussion to ship this as unstable in 0.2? I understand it's all off-by-default, but I'd still like to read the discussion.

A 1M size increase isn't the end of the world but that's also pretty chunky for an off-by-default API too...

Wasmtime GitHub notifications bot (Sep 05 2025 at 13:58):

cdmurph32 commented on PR #6899:

@cdmurph32 do you have a link to the discussion to ship this as unstable in 0.2? I understand it's all off-by-default, but I'd still like to read the discussion.

A 1M size increase isn't the end of the world but that's also pretty chunky for an off-by-default API too...

That's fine. We can wait for 0.3.

Wasmtime GitHub notifications bot (Sep 05 2025 at 14:00):

cdmurph32 submitted PR review.

Wasmtime GitHub notifications bot (Sep 05 2025 at 14:00):

cdmurph32 created PR review comment:

If we want to default to UTC, then I don't see any role for wasmtime at all. There is no host functionality that can be provided.

Wasmtime GitHub notifications bot (Sep 05 2025 at 14:02):

cdmurph32 edited PR review comment.

Wasmtime GitHub notifications bot (Sep 05 2025 at 14:02):

cdmurph32 edited PR review comment.

Wasmtime GitHub notifications bot (Sep 05 2025 at 14:18):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Sep 05 2025 at 14:18):

alexcrichton created PR review comment:

I fear you might be misunderstanding me, but to clarify I'd think of this like environment variables. By default wasmtime doesn't give any environment variables to the guest, but the WasiCtxBuilder structure has methods to pass environment variables. The default behavior of "nothing" doesn't mean that the implementation of environment variabls is pointless it's just the default behavior.

I'm thinking the same thing for time zones. By default it's UTC, but embedders can easily configure "use this time zone instead" where "this" could be something specific or the system's local time zone. I'm not sure why this behavior would lead to the implementation having no role in Wasmtime. Wasmtime is still providing functionality, time zones and information, and embedders can configure which time zone is reported.

Wasmtime GitHub notifications bot (Sep 05 2025 at 22:21):

cdmurph32 submitted PR review.

Wasmtime GitHub notifications bot (Sep 05 2025 at 22:21):

cdmurph32 created PR review comment:

This would probably be easily smoothed over in a quick chat, but I'll try to articulate my understanding as best I can here. Today, there is nothing technically stopping someone from using timezones in their component and setting the timezone to UTC or whatever timezone they want. If they want to enable host timezone access, they would need something like what this PR provides.
If we want that functionality not to be enabled by default then that's fine. Perhaps that is what you mean.

Where I'm coming from people expect their Wasm applications to work just like their native code. For C2PA, all of our tests run with -S cli -S http --dir .. Too many WASI specific code paths and it just isn't worth the hassle to maintain.
If --dir isn't passed and and file access is denied, then the code panics. Likewise if people don't want the system timezone, then they shouldn't pass the feature flag. If they do want it, then it should just work as like the native code, which is their expectation.

Wasmtime GitHub notifications bot (Sep 05 2025 at 22:26):

cdmurph32 edited PR review comment.

Wasmtime GitHub notifications bot (Sep 05 2025 at 22:28):

cdmurph32 edited PR review comment.

Wasmtime GitHub notifications bot (Sep 05 2025 at 22:28):

cdmurph32 edited PR review comment.

Wasmtime GitHub notifications bot (Sep 05 2025 at 22:28):

cdmurph32 edited PR review comment.

Wasmtime GitHub notifications bot (Sep 05 2025 at 22:29):

cdmurph32 edited PR review comment.

Wasmtime GitHub notifications bot (Sep 05 2025 at 22:30):

cdmurph32 edited PR review comment.

Wasmtime GitHub notifications bot (Sep 06 2025 at 07:11):

rvolosatovs submitted PR review.

Wasmtime GitHub notifications bot (Sep 06 2025 at 07:11):

rvolosatovs created PR review comment:

Could you help me understand why we'd need different code paths?

For the CLI you'd pass something like --inherit-timezone to use the timezone of the host or --timezone $mytz to use some custom one. If you don't specify any - it runs in UTC by default.

In case of an embedding you'd use analogous options on the WasiCtxBuilder

If this functionality does not address your use case, I'd really like to know more about it

Last updated: Dec 06 2025 at 06:05 UTC