Debug serves as an "exception that proves the rule", implying more stability in the unstated case. We can still debate whether to make Display changes, but my point is that we would be more careful about that than we would for Debug.
1 Like
implying more stability in the unstated case.
Yeah, that's the part I strongly disagree with. If one is saying anywhere "beware, nothing has been promised" then that shouldn't have a spooky action at a distance where everywhere that doesn't have a warning suddenly has implied promises. Because that disincentives putting warnings on things when someone files a bug report because it causes negative halo around everything else that doesn't have a warning.
Just because a chainsaw doesn't have a "warning, can cause loss of limbs" label you can't assume that it's safe to use this one on your limbs. The absence of a warning is not a promise.
I'll agree that we might want to be a Iota more careful on Display impls due to the uses encouraged by ToString and FromStr, but that's not the same as having promised stability. And that's why I would also suggest not implementing FromStr for Duration.
4 Likes
The chainsaw is too far into absurdity, but let me try a different analogy.
Debug is like a water faucet labeled non-potable. Most faucets don't say anything about their potability, but if you're in an area with a good water supply, you probably just expect that most are fine, with experience to back that up. If you're being extra careful, you may look for explicitly potable faucets, or sanitize your own water, but you should definitely avoid drinking from the non-potable one.
Rust has a great track record of API stability (good water supply), but it gets fuzzy in this area, whether formatting is part of the stable API or not. For types like integers, I think there's a high expectation that we would never change it, even though we haven't explicitly promised so. If we really want Display for Duration, but want the flexibility to change it, we should explicitly say so.
6 Likes
This strikes me as overly dramatic. The thread was only opened a few days ago, it's about a new feature in std, and there are real choices here that can have real impact. While I don't have a strong opinion myself about what the best format is, I think the discussion is very valuable.
I like the idea of adding a way to print a Duration that has guarantees in the way that Debug specifically does not. However, I also think that std’s Display implementations shouldn't be making notable formatting choices except where there is a near-universally-agreed-upon principal way to format the value (for example, almost everyone expects numbers printed in base 10).
In order to reconcile these considerations, I would like to propose using the same solution as Path: add a method which returns a value that does implement Display. That method can then be named indicating the specific formatting strategy used, or at least, a different one can be created later if in the future the current one is regarded as a mistake. So, we can pick one of .si_seconds() or .iso_8601() and add the other later if there is sufficient demand. (And .as_secs_f64() is already such a formatting method if you squint a bit.)
Of course, it's also possible to add impl Display for Duration now and, if desired, add such a method later as an alternative. But I think that is less elegant.
15 Likes
Duration is no simpler than dates. At least unless you want to print duration of 3 years in seconds, you still have to make some decisions how to split it and which units to use (Duration can't actually represent duration of 3 years, it can only represent 1095 days, while 3 years is sometimes 1096 days depending on which 3 years).
Indeed. Display is not usable for localized formatting. And for timestamps and duration not really for anything intended for human consumption, since the format needs to be specified in more detail than the Duration trait allows. But I second the idea to use ISO-8601; that is unambiguous and helpful when writing things that are meant to be parsed back or by some other program.
1 Like
I think it would be perfectly fine to display a 3-year Duration in seconds. The Duration API doesn't have methods for any unit larger than seconds.
I strongly prefer it over the bizarre ISO thing that is hard to understand for any span of time. I know I previously said I don't care how duration is formatted, but ISO duration is so bad that I started caring 
5 Likes
We should also just impl Dispaly for Path, the .dispaly() is a clear net-negative from where I stand . There are two alleged purposes for having .display():
- Preventing the user from making lossy conversions when interfacing with OS API:
cmd.args(&["--home", &path.to_string()]). - Making the programmer think about appropriate way to display a non-utf8 path to the user.
From my experience, 1 definitely doesn't work out: users who don't know Path/String distinction just use Strings throughout and use to_str().unwrap(), users who know and honor the distinction just have to make extra hops for error messages and such (often just using {:?} for paths).
2 just never ever happens at all, I think I've seen zero programs who cared to customize Path's display. I've seen two cases where paths were substituted for cutstom domain types instead (the camino library for utf8-only paths,and I think mercurial just uses Vec for paths)
2 Likes
I would extend the current Debug formatting to also go up to minutes, hours, and days.
There is no API for hours and minutes, but I don't see why it wouldn't be reasonable to add API for minutes, e.g. Duration::from_hours(2).
So it would look like this:
- If less than 1 μs:
123 ns - else if less than 1 ms:
123.456 μs - else if less than 1 s:
123.456789 ms - else if less than 1 minute:
12.123456789 s - else if less than 1 hour:
12 min 34.123456789 s - else if less than 1 day:
2 h 12 min 34.123456789 s - else
3 d 12 h 50 min 30.123456789 s
The units all conform to internationally accepted units.
2 Likes
you forgot about leap seconds and/or daylight savings time shifts, which makes some days longer or shorter than others...
imho we should display durations as a number of hours, minutes, and seconds if we decide we want more than just a number of seconds, not that using ms/us/ns for very small durations is bad.
1 Like
According to the SI brochure, page 145, these units of time are defined as: 1 min = 60 s, 1 h = 60 min, 1 d = 24 h. So I think these are perfectly fine units to use.
Some time scales have leap seconds and summer time, but that is irrelevant to how a Duration is presented.
These considerations would be relevant to displaying a timestamp in a timezone, or to a computation of the Duration between two UTC or PST timestamps, or to adding a Duration to a UTC or PST timestamp, but these are different problems from just displaying a Duration.
9 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.