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

Draft: Proposed clocks improvements #71

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

ptomato
Copy link

@ptomato ptomato commented Jul 10, 2024

See #69 (comment). This is intended as a starting point for discussion about what's possible.

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.
@ptomato ptomato marked this pull request as draft July 10, 2024 00:32
wit/timezone.wit Outdated Show resolved Hide resolved
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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part should probably be removed or reworded, given that instants do not have time zones.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,
Copy link

@bakkot bakkot Jul 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ptomato force-pushed the proposed-clocks-improvements branch from c8c3316 to 205bdc8 Compare July 11, 2024 18:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants