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.

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

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.

:-(

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"

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.

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.

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

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

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.