Following up on #689 and WebAssembly/wasi-clocks#61 (comment), we likely want to make changes to the @unstable timezone proposal based on feedback. This is exactly what the unstable status of this extension was for, so I'm happy we're able to iterate on it - thanks to everyone who has provided feedback so far!

Current API

package wasi:clocks@0.2.0;

@unstable(feature = clocks-timezone)
interface timezone {
    @unstable(feature = clocks-timezone)
    use wall-clock.{datetime};

    @unstable(feature = clocks-timezone)
    display: func(when: datetime) -> timezone-display;

    @unstable(feature = clocks-timezone)
    utc-offset: func(when: datetime) -> s32;

    @unstable(feature = clocks-timezone)
    record timezone-display {
        utc-offset: s32,
        name: string,
        in-daylight-saving-time: bool,
    }
}

Summary of challenges

1. in-daylight-saving-time cannot be (easily) implemented in the browser Implementing in-daylight-saving-time flag #689
2. in-daylight-saving-time has corner cases, and probably should not just be provided as a boolean isDST() of Africa/El_Aaiun returns incorrect value despite UTC offset difference moment/moment-timezone#968
3. timezone offsets should not be measured in seconds, but a more granular time unit Add timezone back in. wasi-clocks#61 (comment)
4. timezone name should be a software-friendly identifier from the IANA Time Zone Database, it's unclear whether that's the case right now

cc/ @justintgrant - did I summarize your feedback accurately in this issue?