Leap seconds are already a problem for minutes and hours, which is probably why they weren't added until now.

That sounds like an irrelevant problem though. A duration is explicitly not concerned with daylight savings at all, I've always thought of it as the amount of actual time (i.e. from a monotonic clock) that has elapsed between two absolute times. So a time diff between noon on daylight savings change day and the day prior would either be 23 or 25 hours, not exactly equal to Duration::from_days(1). There's no time zone or even year context for Duration::from_days(1), so it should always be defined as a naïve calculation involving fixed definitions for hours per day and seconds per hour.

Years are a bit more controversial, to the point where 365 days and 365.24 days are both acceptable in different contexts, and that latter value could change in the very long term (millions of years). But I think up to days, most can agree that the value assumes exactly 24 hours and is completely separate from the idea of wall clocks changing based on local law.

Now, if we want to support "logical" time math, add that to the date/time methods likelogical_add(Duration) that adds/subtracts daylight savings hours and leap seconds as needed so if you add a multiple of 24 hours, you'll get the same wall clock time just on a different day. Maybe chrono does that, IDK, but it would be nice to have day resolution supported at the stdlib level for simple cases where I'm looking for day chunks. It's not a big deal, and Duration::from_hours(24) is plenty readable.

Yes that's true, but the point is you should have to opt in to surprising or risky behaviour.