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

fix: remove hours limit for parseDuration #7064

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

limkhl
Copy link

@limkhl limkhl commented Sep 22, 2024

Closes #5416

image

As mentioned in the issue, I reviewed the Temporal.Duration spec to align the behavior. It seems that the hours value can go up to 130 and beyond, with no explicit maximum limit. Therefore, I’ve adjusted the maximum value to be Infinity.

The previously invalid case P18Y7MT30H15S is valid in Temporal spec, as it returns:

{
    years: 18,
    months: 7,
    weeks: 0,
    days: 0,
    hours: 30,
    minutes: 0,
    seconds: 15
}

As a result, I’ve updated the test case accordingly.

Additional Notes: Currently, only the hours property has had its maximum value limit removed, but properties like years, months, minutes, and seconds should also not have maximum limits. To fully align with the Temporal.Duration specification, I think it’s necessary to remove the maximum value restrictions for all these properties.

✅ Pull Request Checklist:

  • Included link to corresponding React Spectrum GitHub Issue.
  • Added/updated unit tests and storybook for this change (for new code or code which already has tests).
  • Filled out test instructions.
  • Updated documentation (if it already exists for this component).
  • Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

@limkhl limkhl changed the title fix: allow durations with hours > 23 fix: remove hour Limit for parseDuration Sep 22, 2024
@limkhl limkhl changed the title fix: remove hour Limit for parseDuration fix: remove hours limit for parseDuration Sep 22, 2024
- Removes 23-hour limit on duration parsing
- Allows parsing of durations like "PT36H" to work correctly
- Aligns behavior with Temporal.Duration spec which has no upper limit on hours
Copy link
Member

@snowystinger snowystinger left a comment

Choose a reason for hiding this comment

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

seems fine on the surface, will double check with others if there was a reason we did this internally

@snowystinger
Copy link
Member

message from original implementer

The limits incorporated were a result of trying to adhere to the ISO8601 standards for a Duration string
My understanding is that based on ISO8601 standards, date and time values can’t exceed their moduli - so a duration string of P18Y7MT30H15S would not technically be a valid in ISO8601 standards
However based on the temporal spec (and the example you shared that the spec accepts overflow), I did a quick test and navigated to https://tc39.es/proposal-temporal/docs/duration.html#new-Temporal-Duration and input the following in the browsers console: Temporal.Duration.from('P18Y7MT30H15S') and no errors are thrown. So that would suggest to me that the temporal spec does indeed accept overflow, despite ISO8601 standards suggesting otherwise

Seems like there was a discrepancy in the specs, but I think we're ok to go ahead with this, though we should really do it for all the fields asap, otherwise we're going to have a weird state in the API during the transition

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

Successfully merging this pull request may close these issues.

parseDuration prohibits carry over values
2 participants