I could not find a good reason in your code nor in the time package godoc, so I digged into the code a bit.

In particular, after some debugging, I came to this comment:

case '.': // .000 or .999 - repeated digits for fractional seconds.

In other words, any number of 9 digits to signal fractional seconds are only valid format if they follow a period.

Without knowing too much about how the time package works or what's the design behind these layouts, it seems to me like this restriction could be avoided. I'll play with it for a bit to see what I get. Would like some input from @rsc as per https://golang.org/s/owners.

To clarify - 000 cannot be used in place of .000 easily, as it introduces certain ambiguity with others like 01 or 02. However, 999 doesn't seem to have that problem.

Since you know the exact layout, it's easy enough to modify the input string to have the dot that the format requires. I'm not sure this is worth changing.

I'm already working around it by modifying the input string and adding a ..

I was just wondering that there is a . required and could not find or think of any good reason for it. Modifying the string gives me additional points of failure, e.g. if the string is not the format or length I was expecting.

Of course I can give it a try if you'd like a PR. Never done that for the go standard library though.

I would say we first need to decide if we want this change or not. That is, to allow 9999 as well as .9999. The change itself isn't complicated - I have a working version stashed on my laptop.

A decimal point followed by one or more zeros represents a fractional
second, printed to the given number of decimal places. A decimal point
followed by one or more nines represents a fractional second, printed to the
given number of decimal places, with trailing zeros removed. When parsing
(only), the input may contain a fractional second field immediately after
the seconds field, even if the layout does not signify its presence. In that
case a decimal point followed by a maximal series of digits is parsed as a
fractional second.

There is no decimal point here. This is probably working best as is.

Just to throw in another argument:
The German language for example would not use a . but a , for separating fractional seconds. That case is also not covered by the current implementation.