pretty-ms

The fixed can cause durations just below an exact second/minute to round up when seconds are intended to be truncated. A smaller scale-aware tolerance avoids crossing these boundaries while retaining protection from floating-point imprecision. I have a two-file fix with regression tests in this commit. The repository currently restricts opening pull requests to collaborators, so I am reporting it here instead.

With , the sub-second component is rounded independently of the seconds, so a fractional value near the boundary rounds up to and is emitted as its own unit — an impossible combination: The milliseconds unit only ranges 0–999, so should never appear. This is the same "rounding rolls a unit past its max" class as the seconds→ issue (#38), which is handled for seconds by flooring (), but the separate-milliseconds component still used a bare . Fix Cap the rounded component at so it stays within range: Output becomes / — valid unit combinations, consistent with how the seconds component is kept below 60. Non-boundary values are unaffected ( → , → ). Tests Three regression cases added to the test; they produce the impossible output before the change and pass after. Full suite green.

I have the following situation: 1. I have and 2. I display , , and to the end-user 3. The result looks wrong because (conceptually) does not equal (due to rounding) Example: Wondering how you'd suggest to handle this? One idea: expose the rounded numeric value alongside the string (e.g. a -style API, or output), so callers can compute the delta from the values as displayed instead of from the raw inputs. Alternatively, an option to format a set of related values consistently (shared unit and precision). The same issue happens in .