-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
treat all offsets as invalid for gaps in civil time #212
Labels
breaking change
Issues that require a breaking change for resolution.
enhancement
New feature or request
Comments
BurntSushi
added a commit
that referenced
this issue
Jan 25, 2025
This will cause Jiff to reject some datetime strings that it previously accepted. This also brings Jiff into line with how Temporal behaves in these case. It is overall safe because it avoids misinterpreting datetimes in the future that are serialized before a change to DST. For example, imagine serializing `2006-04-02T02:30-05[America/Indiana/Vevay]` before you knew that Indiana/Vevay was going to switch to DST (they hadn't previously used DST since 1972). Before that switch, it was perfectly reasonable to think that the datetime was valid. But after the switch, it corresponded to a gap. Jiff will now reject this. Users can still of course change the offset conflict resolution strategy depending on what they want to do (reject, keep exact time or keep civil time). Fixes #212
BurntSushi
added a commit
that referenced
this issue
Jan 25, 2025
This will cause Jiff to reject some datetime strings that it previously accepted. This also brings Jiff into line with how Temporal behaves in these case. It is overall safe because it avoids misinterpreting datetimes in the future that are serialized before a change to DST. For example, imagine serializing `2006-04-02T02:30-05[America/Indiana/Vevay]` before you knew that Indiana/Vevay was going to switch to DST (they hadn't previously used DST since 1972). Before that switch, it was perfectly reasonable to think that the datetime was valid. But after the switch, it corresponded to a gap. Jiff will now reject this. Users can still of course change the offset conflict resolution strategy depending on what they want to do (reject, keep exact time or keep civil time). Fixes #212
BurntSushi
added a commit
that referenced
this issue
Jan 25, 2025
This will cause Jiff to reject some datetime strings that it previously accepted. This also brings Jiff into line with how Temporal behaves in these case. It is overall safe because it avoids misinterpreting datetimes in the future that are serialized before a change to DST. For example, imagine serializing `2006-04-02T02:30-05[America/Indiana/Vevay]` before you knew that Indiana/Vevay was going to switch to DST (they hadn't previously used DST since 1972). Before that switch, it was perfectly reasonable to think that the datetime was valid. But after the switch, it corresponded to a gap. Jiff will now reject this. Users can still of course change the offset conflict resolution strategy depending on what they want to do (reject, keep exact time or keep civil time). Fixes #212
BurntSushi
added a commit
that referenced
this issue
Jan 27, 2025
This will cause Jiff to reject some datetime strings that it previously accepted. This also brings Jiff into line with how Temporal behaves in these case. It is overall safe because it avoids misinterpreting datetimes in the future that are serialized before a change to DST. For example, imagine serializing `2006-04-02T02:30-05[America/Indiana/Vevay]` before you knew that Indiana/Vevay was going to switch to DST (they hadn't previously used DST since 1972). Before that switch, it was perfectly reasonable to think that the datetime was valid. But after the switch, it corresponded to a gap. Jiff will now reject this. Users can still of course change the offset conflict resolution strategy depending on what they want to do (reject, keep exact time or keep civil time). Fixes #212
BurntSushi
added a commit
that referenced
this issue
Jan 30, 2025
This will cause Jiff to reject some datetime strings that it previously accepted. This also brings Jiff into line with how Temporal behaves in these case. It is overall safe because it avoids misinterpreting datetimes in the future that are serialized before a change to DST. For example, imagine serializing `2006-04-02T02:30-05[America/Indiana/Vevay]` before you knew that Indiana/Vevay was going to switch to DST (they hadn't previously used DST since 1972). Before that switch, it was perfectly reasonable to think that the datetime was valid. But after the switch, it corresponded to a gap. Jiff will now reject this. Users can still of course change the offset conflict resolution strategy depending on what they want to do (reject, keep exact time or keep civil time). Fixes #212
BurntSushi
added a commit
that referenced
this issue
Feb 1, 2025
This will cause Jiff to reject some datetime strings that it previously accepted. This also brings Jiff into line with how Temporal behaves in these case. It is overall safe because it avoids misinterpreting datetimes in the future that are serialized before a change to DST. For example, imagine serializing `2006-04-02T02:30-05[America/Indiana/Vevay]` before you knew that Indiana/Vevay was going to switch to DST (they hadn't previously used DST since 1972). Before that switch, it was perfectly reasonable to think that the datetime was valid. But after the switch, it corresponded to a gap. Jiff will now reject this. Users can still of course change the offset conflict resolution strategy depending on what they want to do (reject, keep exact time or keep civil time). Fixes #212
BurntSushi
added a commit
that referenced
this issue
Feb 2, 2025
This will cause Jiff to reject some datetime strings that it previously accepted. This also brings Jiff into line with how Temporal behaves in these case. It is overall safe because it avoids misinterpreting datetimes in the future that are serialized before a change to DST. For example, imagine serializing `2006-04-02T02:30-05[America/Indiana/Vevay]` before you knew that Indiana/Vevay was going to switch to DST (they hadn't previously used DST since 1972). Before that switch, it was perfectly reasonable to think that the datetime was valid. But after the switch, it corresponded to a gap. Jiff will now reject this. Users can still of course change the offset conflict resolution strategy depending on what they want to do (reject, keep exact time or keep civil time). Fixes #212
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
breaking change
Issues that require a breaking change for resolution.
enhancement
New feature or request
Jiff currently has this behavior:
However, this does not match Temporal's behavior:
I believe this was intentional on my part:
jiff/src/tz/offset.rs
Lines 1590 to 1616 in 94e8270
And indeed, I filed an issue about this here: tc39/proposal-temporal#2892
I find myself agreeing more with Temporal's behavior here. In particular, Temporal returning an error here is meant to catch once-valid-but-no-longer datetime strings because of DST changes. And especially the conservative stance I find appealing: it would be better to return an error here since converting that into a non-error is easier than the reverse.
So for
jiff 0.2
, I'll plan to turn the cases above into errors.The text was updated successfully, but these errors were encountered: