Because approximate durations suffice for casual conversation. When you are talking about the exact date (as computers do) you need something more accurate.

This example isn't about computer communication, it's about John Doe using the windows calculator to find the time between two dates.

Does that matter?

It is clear that the duration between 2015-05-15 [1] and 2019-06-19 is about 2019 - 2015 = 4 years or exactly 1,496 days (or 1,497 days including both endpoints, yeah this is also somewhat ambiguous). It is much less clear that the duration in question is 4 years, 1 month and 4 days; depending on the use case months can be uniformly 30 days long, may or may count the "excess" days, or even do not matter (in which case the duration would be 4 years and 35 days). Generally such a duration is ambiguous without a context and it would be misleading to present it as exact.

[1] https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... (in case you wonder)

I'm not really sure what you're getting it.

June 15th 2015 and July 19th 2019 is 4 years 1 month and 4 days apart. That is the duration that occurred between the two dates and is totally unambiguous to non-programmers.

The fact that calendar distance and 'time' distance don't have a linear relationship and that math that governs the relationship between the different units isn't straightforward doesn't make it unprecise or misleading.

It's totally exact. Just because you can't convert the calendar distance to time distance without context doesn't make it any less exact. Not so different to being unable to compute distance traveled by the revolution count of your wheels.

If you are doing the financial calculation or similar, the month unit is absolutely inaccurate and you will keep asking about edge cases (otherwise you may lose money). And if you don't do that, you can cope with approximate units like months, half-months or so. There is no reason that the exact calculation of duration should be done in approximate units.

Once again, we're talking windows built-in calculator. I really hope the specification is "make it output something that the average user will understand and agree with". And the operative keyword here would be "average".

I'm saying that the Windows Calculator does disservice to the general public by showing the exact-ish year-month-day duration at all, it's like experts oversimplifying the complex situation and making laypersons more confused. Sorry if this was not clear.

Any time you're showing more precision than your inputs or calculations can provide, you're lying to your users.

But the way people use it is not for exact dates and deltas. If today is March and I know something will happen in August, I'll say "this will happen in 5 months from now", but I've never heard anyone add days and weeks to such a duration. If today is 31st o'March and you tell me "next month", that could mean anything between one or thirty days, i.e. the difference between 31st o'March and 1st o'April is one month.

Edit: Also the same way that "tomorrow" can be in 5 minutes.