Hi Zefram,
> From: Zefram [mailto:[email protected]]
>
> Andrew O'Brien wrote:
> >Can anyone explain why parse_duration() gives me 11 days, 8044 minutes
> plus change? (that's around 5.5 extra days) ?
>
> 8044 minutes is 134 hours plus 4 minutes. You also got 5 seconds
> instead
> of the expected 45. So altogether you got 11:0134:4:5 rather than the
> expected 11:01:34:45. The digits are being misallocated. This happens
> because you didn't say how many digits the hours, minutes, and seconds
> should have, so they're allowed one or more by default, and the first
> of them (hours) greedily takes as many digits as it can get away with.
> The parsing is done by a regexp underneath, and the regexp is something
> like /(\d{8})(\d+)(\d+)(\d+)\.(\d+):000/. It all works if you give
> everything explicit field widths, "%8e%2H%2M%2S.%9N:000".
Thanks for this explanation - it makes complete sense and in hindsight is
completely obvious. To explain my confusion I did assume a little more DWIM
given the following from the perldoc:
<--- begin --->
Patterns
This module uses a similar set of patterns to strftime. These patterns
have been kept as close as possible to the original time-based patterns.
...
%H The number of hours zero-padded to two digits.
...
Precision can be changed for any and all the above values. For all but
nanoseconds (%N), the precision is the zero-padding.
<--- end --->
So my assumption was that the default precision for %H would be 2 if not
specified.
Of course, as has been pointed out, this only applies to output but its not
explicitly stated that it doesn't apply to input scanning.
Worth a doc patch or is it just me that finds this slightly confusing?
Cheers,
Andrew
