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.

Sign up for GitHub

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

Jump to bottom

switch to Etc/Unknown when TimeZone::system() could not find a system configured time zone #230

Closed
BurntSushi opened this issue Feb 1, 2025 · 1 comment
Closed

switch to Etc/Unknown when TimeZone::system() could not find a system configured time zone #230

BurntSushi opened this issue Feb 1, 2025 · 1 comment
Labels
breaking change Issues that require a breaking change for resolution.

Comments

@BurntSushi
Copy link
Owner

This time zone is the same as UTC, but it's now officially reserved by the IANA Time Zone Database such that it will be a valid identifier. I believe icu uses it as a useful indicator that a system time zone could not be found instead of just silently using UTC.
@BurntSushi BurntSushi added the breaking change Issues that require a breaking change for resolution. label Feb 1, 2025
@BurntSushi
Copy link
Owner Author

I also wonder also if Etc/Unknown should result in a -00:00 offset (where today UTC results in +00:00). This might be an issue in practice since a jiff::tz::Offset cannot differentiate between negative and positive zero.

BurntSushi added a commit that referenced this issue Feb 1, 2025
@BurntSushi
tz: add TimeZone::unknown() as a fallback in TimeZone::system()
6d86782 
Basically, instead of just logging a warning and falling back to `UTC`,
we now still log a warning and fall back to a time zone that _behaves_
as `UTC`, but is identified as `Etc/Unknown`. This avoids unrecoverable
failure while still also surfacing the fact that "something" has gone
wrong somewhere.

While doing this, I also fixed a bug where Jiff would perform offset
conflict resolution for `Z` offsets. But it shouldn't do that, since `Z`
reflects an unknown offset. In that case, we always respect the `Z`
offset (as numerically equivalent to `+00:00`) in order to resolve the
instant, and then use the time zone to compute the offset for that
instant unambiguously.

Ref tc39/proposal-canonical-tz#25
Closes #230
BurntSushi added a commit that referenced this issue Feb 2, 2025
@BurntSushi
tz: add TimeZone::unknown() as a fallback in TimeZone::system()
ac45de0 
Basically, instead of just logging a warning and falling back to `UTC`,
we now still log a warning and fall back to a time zone that _behaves_
as `UTC`, but is identified as `Etc/Unknown`. This avoids unrecoverable
failure while still also surfacing the fact that "something" has gone
wrong somewhere.

While doing this, I also fixed a bug where Jiff would perform offset
conflict resolution for `Z` offsets. But it shouldn't do that, since `Z`
reflects an unknown offset. In that case, we always respect the `Z`
offset (as numerically equivalent to `+00:00`) in order to resolve the
instant, and then use the time zone to compute the offset for that
instant unambiguously.

Ref tc39/proposal-canonical-tz#25
Closes #230
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
breaking change Issues that require a breaking change for resolution.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@BurntSushi