Hi Zefram, > From: Zefram [mailto:zef...@fysh.org] > > 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