`time::Time` precision

[white-echidna]

It is often needs to relax time precision requirements. Suppose we need to design the train tickets selling system. So we need the ticket representation in our program. Every ticket has a departure time and an arriving time and we want show it in our representation. Usually, trains schedule builds with minute precision (without seconds or nanoseconds), so we want to store the minutes and hours of departure and arriving. And, as trains may travel long distances, we want to store the date and time with utc offset. Summarizing, time::OffsetDateTime is most suitable type for us. And here we got into trouble. If we want to be able to compare departure or arriving times, we must keep invariant that nanoseconds (and seconds) will always be zero. And the library will not help us. It is all on us. Also we have to store at least 5 extra unused bytes for each time instance in our program.

I suggest to provide different Time types for each one precision quality and add suitable cross-operations between them. I would like to discuss the exact design, but for further reading suppose we have type Time with generic parameter precision.

[jhpratt]

There is absolutely no way you would have known this — I never wrote anything publicly or pushed relevant code — but I have tried to implement limited precision for Time before. This is absolutely something I want to do. Unfortunately, doing so ergonomically is quite difficult and requires a handful of nightly features to do it in the manner I would like. Notably, I do not want to create a separate type, but retrofit it onto the existing set of types.

I'm sure there are more, but a quick look shows at least these features that are required or most likely required before this could happen:

• const traits
• improved ergonomics for default generics on structs
• ADT const params
• possibly generic consts

A dedicated type for timestamps is doable, but would involve similar challenges. It would also be more difficult to add in a backwards-compatible way (though possibly easier with const traits) as the existing methods return primitive types.

We may just add the unsafe from_unix_timestamp_unchecked method to time::OffesetDateTime. And users will have the ability to write their own wrappers.

This is doable, but it would be no different than .unwrap_unchecked() on the result of from_unix_timestamp.

[jhpratt]

A Timestamp type is now available on main, so I've narrowed this issue to be about specifying precision for Time (which remains blocked).