[Bug]: Encoding ISO8601 Duration to Numeric Values Causes Ambiguity

[joheredi]

Describe the bug

Encoding ISO8601 duration to seconds or any other numeric value can be problematic when the duration includes non-zero values for days, weeks, months, or years without additional metadata. For example, encoding P1Y (1 year) to seconds requires a reference point to accurately determine the number of seconds. Depending on the reference point, a year can have 365 or 366 days. Similar issues arise with months, weeks, and days.

Suggested Solutions:

• Disallow encoding ISO8601 durations to numeric values and maintain the original format.
• Implement a mechanism to disambiguate the encoding by providing additional metadata or reference points.

Additional Information: This issue affects any service that relies on precise duration encoding and can lead to significant inaccuracies in time-based calculations.

Reproduction

This is a simple spec

Depending on the client implementation the service may receive different values for the same ISO8601 string P1Y

Checklist

• [X] Follow our Code of Conduct
• [X] Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• [X] Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• [X] The provided reproduction is a minimal reproducible example of the bug.

[timotheeguerin]

Technically the duration in tyepspec is not an ISO8601 duration it is just the concept of a duration.

Seeing also what the new JS api does for this is intresting.

I am assuming what we are saying here is that if you serialize this duraiton as seconds then you cannot represent it using those y, m w

[joheredi]

Yeah you can't use year, month, week or day without a reference point. I think this is likely to surface ambiguity, the actual encoded value will depend on how emitters interpret and encode durations to seconds.