You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(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.
The text was updated successfully, but these errors were encountered:
(This is another issue where I'm asking a question to help aide my own understanding.)
Given this code snippet:
I get this exception:
Similarly, for this code snippet (the only change from above is the offset):
I get this exception:
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 that2024-03-10T02:30-04:00[America/New_York]
unambiguously refers to2024-03-10T06:30Z
and2024-03-10T02:30-05:00[America/New_York]
unambiguously refers to2024-03-10T07:30Z
. In the former case, the correct zoned instant is actually2024-03-10T01:30-05:00[America/New_York]
, and in the latter case, it's2024-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 thatoffset: 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.The text was updated successfully, but these errors were encountered: