Add millis to format_duration

[artem-zinnatullin]

Closes #258.

Shows precision of the unit previous to the major time unit.

Like this:

• Over a second — show millis
• Over a minute — show seconds
• Over an hour — show minutes

Includes Rust update to use as_millis, release notes: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1341-2019-04-25

---

Example of output (combined with #256):

-------- TEST STARTED (pull mode = 'serial') test_local_ignore.sh --------
:: Mainframer v3.0.0-dev

Pushing...
Push done: took 0.193 seconds.

Executing command on remote machine...

echo noop

noop

Execution done: took 0.137 seconds.
Pulling...
Pull done: took 0.177 seconds

Success: took 0.537 seconds.

-------- TEST ENDED (pull mode = 'serial') test_local_ignore.sh --------

[arturdryomov]

0.0 seconds, 1.0 seconds and friends look weird. So does 0.500 seconds. Can we have 1.2 seconds and 200 milliseconds at the same time?

[JayNewstrom]

Is a build in milliseconds realistic? The builds I do will always take well over 1 second.

[artem-zinnatullin]

Subsecond builds are not possible most of the time, however knowing where latency comes from is important. The better (unless annoying) we show it the more users would care about optimizing their configurations.

I for one defintely pay attention to duration output of my build tooling and try to optimize remaining tail latency

[artem-zinnatullin]

0.0 seconds, 1.0 seconds and friends look weird. So does 0.500 seconds. Can we have 1.2 seconds and 200 milliseconds at the same time?

I can agree to always showing 3 digits, would that be fine with you? Like this:

0.863
1.200
1.358
1.000

[arturdryomov]

I can agree to always showing 3 digits, would that be fine with you? Like this:

Nope, sorry. 1.000 is unnecessary verbose. We format it for humans, not for machines or statistic tools on top.

[artem-zinnatullin]

You'll never see exactly 1.000, you know that.

1 digit after . is not enough for me, 2 is weird thus why 3 (milliseconds, 1/1000 of a second).

[arturdryomov]

Yes, .000 is the corner case for sure, but the question is a bit different. Do we even care about such precision? Do users care about it? It’s one thing to see took 47 seconds and another took 47.254 seconds. I thought the idea was to show millis when we show 0 seconds, this is awkward.

[artem-zinnatullin]

Maybe I didn't describe idea well enough, sorry about that.

Idea is that in relatively short timings (< 60 seconds) milliseconds matter, of course it doesn't matter when we're talking minutes.

I guess a rule of thumb could be to show previous precision of the major time unit.

Like this:

• Over a second — show millis
• Over a minute — show seconds
• Over an hour — show minutes

[arturdryomov]

I can get behind these rules. Is it covered by the current change or you’ll need adjustments?

[artem-zinnatullin]

To clarify, this PR doesn't follow that rule of thumb ^, I just came up with it to have better description of what was the motivation behind the change

[artem-zinnatullin]

---- RACE CONDITION DETECTED ----

ok, now that we have agreement I'll adjust PR

[artem-zinnatullin]

Done! Also, had to update Rust because as_millis wasn't stable lol

#[stable(feature = "duration_as_u128", since = "1.33.0")]
#[inline]
pub const fn as_millis(&self) -> u128 {

[artem-zinnatullin]

PR description updated accordingly.

[artem-zinnatullin]

@ming13 can you ptal?

[artem-zinnatullin]

cc @sboishtyan

[artem-zinnatullin]

and @Tagakov

[arturdryomov]

@artem-zinnatullin, can we use a magical Rust package for this? I hope Rust is not that bad that there is no time formatting tool around.

[artem-zinnatullin]

We prob can, but really the code is so tiny that it's not a big deal I think

[artem-zinnatullin]

But if someone finds such a package, I'm def down to take a look at it

[arturdryomov]

@artem-zinnatullin, chrono_humanize probably should work. Wasn’t updated for year though.