hms parsers: negative components vs negative period

[alchenist]

The ability to handle negative components in the hms parsers (from commit a8ade12 fixing #333) is welcome. However, I commonly encounter periods where the #dicated at the beginning applies to the entire period, where we would expect_that(hms("-01:30:00"), equals(hours(-1) + minutes(-30) + seconds(0))). Current behavior would pass this instead: expect_that(hms("-01:30:00"), equals(hours(-1) + minutes(30) + seconds(0)))

Should there be support for cases where individual components take the initial sign, in addition to cases where each component is signed?

[vspinu]

Where do you encounter such format? Is there a standardized rule for such format somewhere?

The only option I see is to add an extra argument to hms for this case.

[alchenist]

Not quite; I don't think there's a standard for either representation of negative durations, but leading negatives for multi-part durations do have precedent: see the interpretation of ISO 8601 durations in the W3C XML schema datatype spec, which allows for a preceding minus # front of the entire duration to indicate a negative duration and only allows unsigned components.

An optional preceding minus sign ('-') is allowed, to indicate a negative duration. If the sign is omitted a positive duration is indicated.
...
P-1347M is not allowed although -P1347M is allowed.

Other parsers, like Moment.js, also only allow mixed signs within a single duration.

As of 2.13.0, mixed negative and positive signs are supported when parsing durations.
moment.duration('PT-6H3M')

[vspinu]

So what would you suggest in terms of UI? We actually need to implement ISO 8601 anyways, so maybe just go that way?

[vspinu]

I am inclined to have mixed signs within durations. Making negative duration is easy by unary - after the parsing.

[vspinu]

I decided not to take any action on this. Preprocessing leading - in a string is trivial, and negating the whole duration is immideate with unary - after parsing. It's just not worth the implementation complexity, especially that the compatibility preserving UI is not obvious.

Something to consider for potential lubridate's rewrite though.

[bbolker]

This came up again: https://stackoverflow.com/questions/77614470/r-hms-converts-negative-values-to-positive-but-shouldnt/77614817#77614817

Would a pull request for a change to the documentation that clarifies this point be considered ... ?