Skip to content

Should "format": "duration" allow fractional seconds? #1603

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

Open
GREsau opened this issue May 23, 2025 · 4 comments
Open

Should "format": "duration" allow fractional seconds? #1603

GREsau opened this issue May 23, 2025 · 4 comments

Comments

@GREsau
Copy link

GREsau commented May 23, 2025

Draft 2020-12 7.3.1. Dates, Times, and Duration states:

Date and time format names are derived from RFC 3339, section 5.6. The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339.

  • ...
  • duration: A string instance is valid against this attribute if it is a valid representation according to the "duration" ABNF rule (referenced above)

And the relevant section from RFC 3339:

Durations:

   dur-second        = 1*DIGIT "S"
   dur-minute        = 1*DIGIT "M" [dur-second]
   dur-hour          = 1*DIGIT "H" [dur-minute]
   dur-time          = "T" (dur-hour / dur-minute / dur-second)
   dur-day           = 1*DIGIT "D"
   dur-week          = 1*DIGIT "W"
   dur-month         = 1*DIGIT "M" [dur-day]
   dur-year          = 1*DIGIT "Y" [dur-month]
   dur-date          = (dur-day / dur-month / dur-year) [dur-time]

   duration          = "P" (dur-date / dur-time / dur-week)

Following this to the letter would mean that fractional seconds are not valid, e.g. "PT0.5S" (half a second) is not a valid duration. While there's no test in the JSON Schema test suite for this, the few validators that I tested do match this behaviour i.e. they disallow fractional seconds.

While this behaviour is not necessarily "incorrect", nor is it ambiguous, I'm concerned that it limits the utility and interoperability of the duration format, and is counter to consumer expectations. For example:

Now that I think about it, the same issue exists for negative durations, e.g. "-PT1S" (negative one second) is not a valid duration according to JSON Schema, despite being widely supported by various standards based on ISO 8601.

@gregsdennis
Copy link
Member

That's an interesting question, and I'm sure there could be use cases for it. Have you seen usages of RFC3339 duration with fractional seconds in a context where they're claiming to follow the RFC?

We typically follow a strict interpretation, so I'd imagine these would be disallowed. I'd be open to including an allowance in the next version, though.

@GREsau
Copy link
Author

GREsau commented May 23, 2025

Have you seen usages of RFC3339 duration with fractional seconds in a context where they're claiming to follow the RFC?

I haven't actually seen usages of RFC3339 duration at all.

That spec doesn't really make any attempt to define or standardize durations outside of appendix A, which is just an attempt at defining a formal grammar for ISO 8601. That appendix also states that it is "informational only and may contain errors" - in my opinion, the absence of negative/fractionals is exactly that, an error

@gregsdennis
Copy link
Member

That's good info. Thanks. It's probably the start of a strong case to start supporting ISO 8601 instead with the next spec version.

@gibson042
Copy link
Contributor

Note that full ISO 8601 includes a lot of representations that should probably not be available here, such as P0.5M (section 5.5.2.3: «The lowest order component may have a decimal fraction.»), and excludes some representations that might belong, such as P1M1W1D (section 5.5.2.2.: «The complete representation of the expression for duration shall be one of: a) [“P”][i][“Y”][i][“M”][i][“D”][“T”][i][“H”][i][“M”][i][“S”]; b) [“P”][i][“W”].»)—and also some that could go either way, such as PT1,00H (section 3.2.6: «the “.” period and “,” comma characters are decimal sign used to separate the integer part from the decimal fraction of a number»). Temporal is explicit about these: https://tc39.es/proposal-temporal/#sec-temporal-iso8601grammar

RFC 9557 and ISO 8601 are similar, but ISO 8601 defines a number of optional deviations that are allowed "by agreement between the communicating parties". The following is a list of deviations supported by this grammar:

  • Anything else described by ISO 8601 as requiring mutual agreement between communicating parties, is disallowed.

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

3 participants