On Thu, Sep 1, 2016 at 3:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Corey Huinker <corey.huin...@gmail.com> writes: > > On Thu, Sep 1, 2016 at 2:43 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Note that times from 1 second to 1 hour all get the nn:nn.nnn > >> treatment. I experimented with these variants for sub-minute times: > >> ... > >> but it seems like the first variant is not terribly intelligible and > >> the second variant is inconsistent with what happens for longer times. > > > Well, if we're looking to be consistent, here's what interval does now: > > ... > > Should we just plug into whatever code that uses? > > Well, that code's on the backend side so we're not going to just call it > in any case. And I think we don't want to be quite so verbose as to go up > to hh:mm:ss.fff as soon as we get past 1 second. However, comparing that > output to what I had suggests that maybe it's better to keep a leading > zero in two-digit fields, that is render times like "00:01.234", > "01:23.456", or "01:23:45.678" rather than suppressing the initial zero as > I had in my examples. It's an extra character but I think it reinforces > the meaning. > > regards, tom lane >
+1 The larger jump in widths from no MM:SS to HH:MM:SS is a good visual cue. Jumping from MM:SS to H:MM:SS to HH:MM:SS would be more subtle and possibly confusing.
