Draft: Proposed clocks improvements #71
Conversation
Other possibilities: "monotonic-time", "clock-point" (if the "monotonic-clock" namespace is sufficient and we don't need to repeat 'monotonic'), "timestamp". Also renames monotonic-clock::subscribe-instant to subscribe-clock-point. Other possibilities: "subscribe-monotonic-clock-point", "subscribe-time", "subscribe-monotonic-time", "subscribe-timestamp".
Other possibilities: "system-time", "exact-clock", "exact-time", "current-time", etc. I propose "system-clock" because referring to it as a clock makes sense, within the WASI Clocks interface.
wit/timezone.wit
Outdated
| /// If the timezone cannot be determined for the given `datetime`, return a | ||
| /// `timezone-display` for `UTC` with a `utc-offset` of 0 and no daylight | ||
| /// saving time. | ||
| /// If the timezone cannot be determined for the given `instant`, return a |
There was a problem hiding this comment.
This part should probably be removed or reworded, given that instants do not have time zones.
There was a problem hiding this comment.
Now that I read it again, I'm not sure what it means for the time zone to be unable to be determined. I guess if the host doesn't have a concept of "current time zone" it should pretend the current time zone is UTC? I'll assume that's what this means, but let me know if there was a different situation in mind when writing this.
wit/timezone.wit
Outdated
| /// In implementations that do not expose an actual time zone, this | ||
| /// should return false. | ||
| in-daylight-saving-time: bool, | ||
| id: string, |
There was a problem hiding this comment.
Does a user's IANA timezone ID change for different instants in time? If not, maybe this part should be removed from this function and put somewhere else (probably a func() -> string) that does not require an instant as input.
E.g., if someone's time zone is currently Asia/Kolkata, is that still the case if asking about a date-time in 1900, or would that be Asia/Calcutta instead? Or, similarly for time zones which have split or joined at various points in history.
There was a problem hiding this comment.
Good point, there isn't any need for this to be instant-dependent. We could probably go a bit farther and refactor the interface because timezone-display makes less sense without the DST flag. I'll add a commit with how that might look.
Other possibilities: "system-clock-point", "clock-point" (analogous to "monotonic-clock-point"), "exact-time", "absolute-time", "timestamp", "epoch-time".
This flag is problematic because when a time zone is "in DST" is not well defined. Most time zones in the world don't use DST at all. Of the ones that do, most go to DST during the summer for half the year, but not all. For example, the function in Moment.js that provides this functionality comes with a giant caveat: https://momentjs.com/docs/#/query/is-daylight-saving-time/
Other possibilities: "tzid", "iana-id", "identifier", "iana-identifier". Returning a user-displayable name as part of timezone-display would require more information: the user's preferred language, and the preferred style for the name: - abbreviated or not - year-round or specific to the Instant E.g., the time zone with the IANA id "America/Los_Angeles" might be displayed as "Pacific Time", "Pacific Standard Time", "Pacific Daylight Time", "PT", "PST", "PDT", "Nordamerikanische Westküstenzeit"... The Rust iana_time_zone crate uses IANA time zone IDs, so if this interface needs to be able to implement iana_time_zone, timezone-display should have an IANA ID and not a user-displayable name.
There are time zones that used sub-minute or even sub-second UTC offsets for instants in the past. E.g., when built using Vanguard format, the UTC offset in the TZDB for "Asia/Ho_Chi_Minh" before July 1906 is 7:06:30.133333333.
If the timezone-display ID is an IANA ID, and we are going with the
approach of not making the localized ("PST" vs "PDT" vs "PT") name part of
this component, then the current time zone doesn't depend on the current
time.
After removing the isDST flag, timezone-display contains two pieces of
data, the ID and the UTC offset. The UTC offset is already available via
a function that takes an Instant as input. The ID could just be available
via its own function that doesn't take any input.
In that case there would be no need for timezone-display.
ptomato
force-pushed
the
proposed-clocks-improvements
branch
from
c8c3316
to
205bdc8
Compare
See #69 (comment). This is intended as a starting point for discussion about what's possible.