> "2:20:33.1h" is 140 minutes, 33 seconds and 100ms. This one seems very backwards to me, as leading zeros could change the meaning. Ex. 0:1:15h vs 1:15h. If allowing combination units like that (personally, it seems overkill), I think it would be much safer to require an explicit specification as 'hms', 'ms', etc. which must match the delimiter count, or to just use the least significant unit as in '1:30:15.345s'.
Rick Houser Web Administration > -----Original Message----- > From: Stefan Eissing [mailto:[email protected]] > Sent: Tuesday, June 20, 2017 09:13 > To: [email protected] > Subject: Re: Timeouts and other time-related granularity > > > > Am 20.06.2017 um 14:56 schrieb Jim Jagielski <[email protected]>: > > > > Most of our time-related directives accept seconds as their > > parameters, but I'm thinking that allowing milliseconds is > > likely a better option... From what I can see, most of what > > would be interesting/useful to change are stored as interval/apr_time > > anyway, so there would be no real API/struct changes required. > > > > Thoughts? Comments? > > +1 > > I would suggest a common duration syntax for better readability and a > common conversion util function. We can stick to seconds if it is > just a number, but allow fractions for millis etc. So > > "1" is 1 second "0.001" is one millisecond, as is "1ms". > "1.5m" is 90 seconds, as is "1:30m" > "1:15h" is 75 minutes > "2:20:33.1h" is 140 minutes, 33 seconds and 100ms. > "1:60h" is invalid, as is "1:00:00m" and "1:00:00:00" etc.
