Skip to content

Add AccurateDuration and NominalDuration#24

Merged
andimarek merged 4 commits into
graphql:mainfrom
AlexandreCarlton:add-accurate-duration-and-nominal-duration
Jan 26, 2026
Merged

Add AccurateDuration and NominalDuration#24
andimarek merged 4 commits into
graphql:mainfrom
AlexandreCarlton:add-accurate-duration-and-nominal-duration

Conversation

@AlexandreCarlton

Copy link
Copy Markdown
Contributor

This pull request attempts to document two different types of Durations per the ISO 8601 standard:

  • AccurateDuration, relating to the portion of a Duration that is context-free (that is, it only contains seconds, minutes, hours, and 24-hour days).

  • NominalDuration, relating ot the portion that is dependent on the position in the calendar with respect to which the duration is being evaluated. It contains calendar years, months, weeks and days.

Please see graphql-java/graphql-java-extended-scalars#132 for the proposed implementation in graphql-java.

This pull request attempts to document two different types of
Durations per the ISO 8601 standard:

 - `AccurateDuration`, relating to the portion of a Duration that is
   context-free (that is, it only contains seconds, minutes, hours, and
   24-hour days).

 - `NominalDuration`, relating ot the portion that is dependent on the
   position in the calendar with respect to which the duration is being
   evaluated. It contains calendar years, months, weeks and days.

Please see graphql-java/graphql-java-extended-scalars#132
for the implementation in `graphql-java`.
@linux-foundation-easycla

linux-foundation-easycla Bot commented Mar 16, 2024

Copy link
Copy Markdown

CLA Signed

The committers listed above are authorized under a signed CLA.

  • ✅ login: AlexandreCarlton / name: Alexandre Carlton (2b5232f)
  • ✅ login: martinbonnin / name: Martin Bonnin (e068b64)

Comment thread scalars/contributed/AlexandreCarlton/nominal-duration.md Outdated
Co-authored-by: Ivan Maximov <sungam3r@yandex.ru>
@alf

alf commented Mar 31, 2025

Copy link
Copy Markdown

What's needed to make this progress further? We're currently defining our own Duration, but it would be great to standardize.

@dondonz

dondonz commented Apr 5, 2025

Copy link
Copy Markdown
Collaborator

Hello, I'd like to revisit this soon. We're preparing to release the next major version of GraphQL Java now, after that let's come back to this scalar discussion

@martinbonnin martinbonnin requested a review from a team November 28, 2025 23:48
@martinbonnin

Copy link
Copy Markdown
Contributor

@dondonz any news here?

@martinbonnin martinbonnin added the 🌱 new specification Authors decide when new specifications get merged. label Dec 25, 2025
@martinbonnin

Copy link
Copy Markdown
Contributor

2026 cleanup, I'm closing this. If this is still worked on, please leave a comment and I'll reopen.

@andimarek andimarek left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be create to change the Name section into Recommend Name to align with the current template, as name was a confusing section in the past.

The actual Scalar name used is arbitrary and any scalar name can be used with any spec.

# Name

`AccurateDuration`, originating from the wording in
[ISO 8601](https://en.wikipedia.org/wiki/ISO_8601):

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ISO 8601 is always tricky to reference as it is not a public spec and the only source you can really quote is wikipediate, which is not the spec itself.

I don't have great solution for that.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did comb through RFC 3339 in the hopes I could reference this instead, but no dice. I agree it would be better to reference a spec that is public, but most languages offer support for ISO-8601 parsing. I am confident this could be implemented for a majority of GraphQL libraries (it was certainly straightforward to implement for Java).

@andimarek andimarek reopened this Jan 23, 2026
This aligns with the current template as "Name" was confusing in the
past.
@AlexandreCarlton

Copy link
Copy Markdown
Contributor Author

Hey everyone, apologies for the lack of activity. I failed to read the fine print in the README.md:

When they consider the pull request has reached a satisfactory state, but not before a 2 week review window, the author may ask a TSC member to merge the pull request.

I had assumed that it would be merged for me once reviewers were happy with it. I've chatted with @andimarek and if he's happy with the specification after my updates (I personally think it's ready to go) I'll ask him to merge it.

@martinbonnin

Copy link
Copy Markdown
Contributor

@AlexandreCarlton no worries! The text you quote is a recent addition. Thanks for looking into this.

@martinbonnin

martinbonnin commented Jan 26, 2026

Copy link
Copy Markdown
Contributor

@AlexandreCarlton are you OK to merge this? Nevermind, you said you're OK in the message just above, sorry. @andimarek, I'll let you press the merge button when you're ready.

@andimarek andimarek merged commit 02dacb0 into graphql:main Jan 26, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🌱 new specification Authors decide when new specifications get merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants