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.

[jbethune]

This is just my opinion: I would prefer it if the method from_mins(u64) had 3 letters more in the name: from_minutes(u64).

I am aware of the existing methods from_micros, from_millis, from_nanos, from_secs, which all abbreviate "seconds". But from_hours is fully spelled out. And there are the nightly methods from_days and from_weeks.

I understand that we want to achieve consistency. But there is currently no other "minutes" method (but plenty of "seconds" methods). And I think it would be better if we spelled the name out, because all other super-second time units are probably going to be fully spelled out, because they are fairly short in English.

This is just for consideration. Feel free to go ahead if you prefer the abbreviated from_mins name.

[Dietr1ch]

This is just my opinion: I would prefer it if the method from_mins(u64) had 3 letters more in the name: from_minutes(u64).

This is something that bothered me a bit as well, but I guess I just gave up on it since I knew we had from_millis in already and it seemed to me that that ship sailed already.

At Google changes like that one are allowed and done, but they require tooling that updates the entire codebase, and as far as I know there's no tooling to upgrade rust from say 1.89 to 1.90 if that fully spelling change was rolling out in between those versions.

And there are the nightly methods from_days and from_weeks.

And regarding these methods, I guess that the original intention was to keep the abbreviations, but it's probably not possible to abbreviate them in a reasonable, mostly universal way. If there is, I'm happy to update the other methods to regain consistency in using abbreviations, but from the discussions on duration_constructors it seems that we won't get agreement for them unless a full civic time library rolls out in std.