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
I was going over the error conditions for parsing a Temporal ISO 8601 datetime in my Rust library (Jiff) inspired by Temporal, and I stumbled on to this case and wondered if it was intended or not. Specifically, this seems to work right now:
I am wondering if this is intended. And more broadly, what Temporal does with the critcal flag (!) in a time zone annotation.
Depending on how you hold RFC 9557, it seems to suggest that the above should result in an error:
A suffix tag may also indicate that it is critical: The recipient is advised that it MUST NOT act on the IXDTF string unless it can process the suffix tag as specified. A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see critical-flag in Section 4.1).
RFC 9557 also says this:
Note that applications MAY also perform additional processing on inconsistent or unrecognized elective suffix tags, such as asking the user how to resolve the inconsistency. While they are not required to do so with elective suffix tags, they are required to reject or perform some other error handling when encountering inconsistent or unrecognized suffix tags marked as critical.
Which seems to suggest further that the above should result in an error.
I suppose this is perhaps somewhat questionable since parsing an Instant can be done without looking at or caring about the time zone annotation at all. And if the above would return an error, then I suppose one might question whether this should return an error too:
Perhaps one could make the argument that the first case above should be an error and this latter case shouldn't because, in the first case, there is a definitive inconsistency in the data.
In any case, Jiff has the same behavior as Temporal here currently, and I was wondering if it was intentional or not. In my case, I hadn't considered this at all, and the implementation of parsing an instant just completely ignores the time zone annotation (other than verifying that it parses correctly).
The text was updated successfully, but these errors were encountered:
I was going over the error conditions for parsing a Temporal ISO 8601 datetime in my Rust library (Jiff) inspired by Temporal, and I stumbled on to this case and wondered if it was intended or not. Specifically, this seems to work right now:
I am wondering if this is intended. And more broadly, what Temporal does with the critcal flag (
!
) in a time zone annotation.Depending on how you hold RFC 9557, it seems to suggest that the above should result in an error:
RFC 9557 also says this:
Which seems to suggest further that the above should result in an error.
I suppose this is perhaps somewhat questionable since parsing an
Instant
can be done without looking at or caring about the time zone annotation at all. And if the above would return an error, then I suppose one might question whether this should return an error too:Perhaps one could make the argument that the first case above should be an error and this latter case shouldn't because, in the first case, there is a definitive inconsistency in the data.
In any case, Jiff has the same behavior as Temporal here currently, and I was wondering if it was intentional or not. In my case, I hadn't considered this at all, and the implementation of parsing an instant just completely ignores the time zone annotation (other than verifying that it parses correctly).
The text was updated successfully, but these errors were encountered: