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

does ZonedDateTime.from with offset: reject always throw when the datetime is in a DST transition gap? if so, is that intended? #2892

Open
BurntSushi opened this issue Jun 8, 2024 · 0 comments

Comments

@BurntSushi
Copy link

(This is another issue where I'm asking a question to help aide my own understanding.)

Given this code snippet:

let t = Temporal.ZonedDateTime.from(
  "2024-03-10T02:30-04:00[America/New_York]",
  { offset: 'reject' },
);
console.log(t.toString());

I get this exception:

RangeError: Offset -04:00 is invalid for 2024-03-10T02:30:00 in time zone

Similarly, for this code snippet (the only change from above is the offset):

let t = Temporal.ZonedDateTime.from(
  "2024-03-10T02:30-05:00[America/New_York]",
  { offset: 'reject' },
);
console.log(t.toString());

I get this exception:

RangeError: Offset -05:00 is invalid for 2024-03-10T02:30:00 in time zone

Walking through this, I think the reason why these both throw is that the offset in the input wouldn't match the offset in the ZonedDateTime returned. Namely, I believe that 2024-03-10T02:30-04:00[America/New_York] unambiguously refers to 2024-03-10T06:30Z and 2024-03-10T02:30-05:00[America/New_York] unambiguously refers to 2024-03-10T07:30Z. In the former case, the correct zoned instant is actually 2024-03-10T01:30-05:00[America/New_York], and in the latter case, it's 2024-03-10T03:30-04:00[America/New_York]. As you can see, the offset flip flops. I think that is true for every gap. So I think that in turn means that offset: reject always throws for any datetime in a gap, even if it has a correct offset that disambiguates it.

I guess my question here is, is this behavior intended? And if so, what is the rationale behind it? That is, is it preventing the caller from making a mistake somehow? My understanding is that if the offset makes the datetime unambiguous (as I believe it does in this case), then the offset is "valid" and maybe shouldn't result in an error. On the other hand, if offset: reject is just about whether the offset in the input matches the offset in the output precisely, then I think the exception is warranted. I'm just having trouble understanding what would go wrong if the datetimes above were parsed without error.

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

No branches or pull requests

1 participant