Fix DurationRound panics from issue #1010

[pitdicker]

Every time I want to fix the panics in DurationRound, I just can't get my head around how little these methods make sense.

Why would you ever want to round to a duration of 34 seconds? What does rounding to multiples of 12:34:56 mean? What does rounding to Duration::days(3) do? And rounding to a negative number? What if you take things like DST into account? Why can't I round 1970-01-01 00:00:15 to whole hours?

The test cases here attempt to round to -7019067213.869040, -8923838508.697114584, and -9223372036.854771421 seconds 😢 .

I don't want to touch this code too much, but rounding to negative seconds is easy to deny.

[jtmoon79]

The error DurationExceedsLimit suggests something too big. Could another enum be added to RoundingError, like DurationLessThanZero ?

[pitdicker]

That would be a breaking change.

If would prefer it to add a more useful rounding method instead, and forget about this one all together 😄.

---

I couple of weeks ago I was thinking what would be a more sensible rounding method. Some requirements:

• The interval between two rounded values is not important, the target value should appear rounded.
• It should take timezone transitions and leap seconds into account.
  Example: when rounding to multiples of two hours, you would expect the time to be rounded to 0:00, 2:00, 4:00, and not see 3:00 in your output if there happens to be a DST transition that day.
• Anything that is rounding beyond midnight doesn't make much sense.
• There are three useful rounding directions: round to nearest, up and down.
• You want to round to a multiple of some unit:

  enum RoundingUnit {
      Hour(u8),
      Minute(u8),
      Second(u8),
      Nanosecond(u32),
  }

• Rounding to a unit should stap at the boundary to the next unit to remain somewhat sensible. Rounding to 7 seconds (who does that??) should start at 0 at every new minute.

This would take a couple of days to write, and is not that high on my wish list though.