time: ParseDuration fails to parse values consisting of multiple zeros

[iand]

time.ParseDuration returns an error when passed a string consisting of more than one zero but no unit: "time: missing unit in duration 00"

See http://play.golang.org/p/_UklkYQ0I1

I'd expect this to have the same behaviour as parsing a single zero, i.e. return a duration of 0 and no error. Leading zeros are ignored as expected when the supplied string has a unit.

go version go1.5.2 linux/amd64

[earthboundkid]

It looks like the issue is here and here.

Zero alone is a special case, and there's no further parsing done for it. All the real parsing requires a format. The simplest fix would be at the second location to add a check if the captured number is equal to zero.

[earthboundkid]

Hmm, flipside of how the parser works, it accepts crazy values like 3s1m2s: http://play.golang.org/p/kcLlE4bX7p

[earthboundkid]

Is accepting values like 1s1s1s1s considered part of the Go 1.0 API guarantee? If not, it would be fun to rewrite ParseDuration to do proper lexing/parsing with a documented format.

[minux]

It might not be covered by Go 1 guarantee explicitly, but as code might depend on such behavior, we cannot change it.

[earthboundkid]

:-(

I just got done typing up an EBNF:

duration = [sign] hour
sign = "-" | "+"
hour = number "h" [minute] | minute
minute = number "m" [second] | second
second = number "s" [milli] | milli
milli = number "ms" [] | 
micro = number microsign [nano] | nano
microsign = "us" | "μs"
nano = number "ns" | zero
zero = { "0" } [ "." { "0" } ]
number = { digit } [ "."  { digit } ]
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

[robpike]

If it's a bug, we can fix it. The value 00 not being the same as 0 seems like a bug to me, especially for a time value, where 00 is often seen.

[earthboundkid]

Okay. This seems like a pretty simple bug to fix. I've never submitted a Go patch before so I'll have to read all the contributor docs and whatnot first, but I'll try reading them this weekend and see how far I can get.

One question: should I also have it accept 0.0? Seems like we should for consistency with the other zero values we accept.

[earthboundkid]

Note to self, here's a minimal change that seems to fix it: http://play.golang.org/p/L36TxtuMcY

[minux]

FTR, I was referring to the "1s2s3s" case that we can't change. I agree that not being able to parse "00" is a bug.

[gopherbot]

CL https://golang.org/cl/19314 mentions this issue.

[rsc]

Based on CL 19314, I think this is not a bug.
Unitless "0" is a special case.
Let's stop the special there instead of letting it spread.