Tracking Issue for duration_constructors_lite

[Dietr1ch]

Feature gate: #![feature(duration_constructors_lite)]

This is a tracking issue for duration_constructors_lite.

duration_constructors_lite implements the non-controversial bits of duration_constructors.

Public API

• std::time::Duration
  • from_mins(u64)
  • from_hours(u64)

History

(Remember to update the S-tracking-* label when checking boxes.)

• Original duration_constructors implementation core: add Duration constructors #120307
  • Adds new Duration constructors from_mins, from_hours, from_days and from_weeks.
  • Daylight savings time coupled with possible confusion between "standard/scientific/stopwatch" time and "civil/human" time makes using from_days and from_weeks wrong too easy.
  • Without a CivilDuration type to disambiguate Duration as the "standard/scientific" time duration its safer to avoid introducing from_days and from_weeks even if Duration explicitly aims to model "standard/scientific".

Steps

• Implementation: #140882
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Best way to implement from_days and other larger quantities in the future.
  • It seems we need a Civil time type in std to help avoid mis-interpreting std::time::Duration.

Misc

I want to thank all folks who participated in #120301. It's not fun to argue online for so long, but very much needed to grow the language in a sound way as it's even harder to undo mistakes.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[Dietr1ch]

I don't think this feature will change at all. Should I just draft the stabilisation PR? It might seem soon, but this has been discussed for a while in duration_constructors, so waiting here to me would be mostly a formality as the recent changes are essentially non-code ones.

[BurntSushi]

@rfcbot fcp merge

This feature is new, but they represent a less controversial subset of duration_constructors (from #120301) that has been on nightly for quite some time. These routines allow constructing durations from hours or minutes, where as #120301 allows the same but from days or weeks.

One concern that has been raised about the hour/minute constructors is that of leap seconds (since some minutes have 61 seconds and in theory some minutes could have 59 seconds, although a negative leap second has never occurred). In my experience, there is no widespread practice for interpreting an hour as anything different from 60 minutes and interpreting a minute as anything different from 60 seconds, despite the presence of leap seconds. Moreover, our SystemTime type already ignores leap seconds.

As for why these were split out of duration_constructors, see #120301 for a fair bit of discussion.

[rfcbot]

Team member @BurntSushi has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.