Why "1 month" isn't a fixed number of days

The calendar breakdown deliberately works by repeatedly subtracting whole calendar units — years, then months, then days — rather than dividing the total elapsed milliseconds by some fixed average length. That's the only way "1 month" reliably means what a person actually means by it: the same day next month, whether that month has 28, 30, or 31 days. A duration library that instead defines a month as a fixed 30 or 30.44 days will quietly disagree with the calendar the moment the actual months involved aren't that length, which shows up as an answer that's technically consistent with its own internal math but wrong by a day or two against what anyone looking at a calendar would say.

Total hours can differ from what the calendar breakdown implies, on purpose

On a day with a daylight saving time transition, a calendar day is not exactly 24 hours of wall-clock time — it's 23 or 25, depending on which direction the clock moved. The calendar breakdown (years/months/days/hours) stays intuitive across a DST boundary because it's counting calendar units, but the total-hours and total-minutes figures reflect genuine elapsed wall-clock time, so the two can disagree by an hour on a transition day. That's not a bug in either number — they're answering different questions (calendar distance vs. actual elapsed time), and both are useful depending on which one the task at hand actually needs.