Repository navigation
Read ISO 8601 calendar units with a count of zero - #6
Merged
Merged
Conversation
ISO8601 rejected every year, month, week and day, whatever its count, because a calendar unit has no fixed length. A count of zero has one: zero days are no time at all, however long a day is. Real producers write such durations. moment.js and Python's isodate write a zero duration as "P0D", and date-fns writes every component of every duration, as in "P0Y0M0DT1H30M0S". Both were rejected, with and, for years and months, even without AcceptDays. A calendar unit whose count is zero and has no fraction is now read in every mode, by With, the wrapper types and Format.Parse alike. A count with a fraction, as in "P0.0D", stays an error, as it is with AcceptDays. The reference parser follows the same rule, and the compat tests list the new difference from the format tag option, which rejects these durations.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Finding 1 of the full review, and the only change of behavior in this round.
ISO8601rejected every year, month, week and day because a calendar unit has no fixed length. With a count of zerothat reason does not hold: zero days are no time at all, however long a day is. And real producers write such
durations:
"P0D"ErrCalendarUnits0s"P0D"ErrCalendarUnits0s"P0Y0M0DT1H30M0S"ErrCalendarUnits, even withAcceptDays1h30m0sThe rule: a year, month, week or day whose count is zero and has no fraction adds nothing and is no error, in every
mode (
With, the wrapper types,Format.Parse). Everything else is as before:"P0Y1D"and"P1Y0D"are calendarunits,
"P0.0D"isErrCalendarUnitswithoutAcceptDaysand a syntax error with it,"P0DT"is a syntax error.FuzzParseMatchesReferencefound no disagreement.formattag option, which rejects these durations, andFuzzUnmarshalMatchesFormatTagran for 30 seconds without a finding.After the CI and tooling PR merges, this branch needs main merged in: both touch
internal/compat/compat_test.go.