The trouble seems to be here. The code is assuming that _2 is a date example. So, the next token it finds is "006". That's unrecognized by the zero pattern, so the error is thrown.

Not sure how to fix this. The whole model of specification-by-example seems curious to me. Suppose I (oddly enough, admittedly) wanted to use the sequence "02" as my separator - in an example it would look like this: Mon02Jan022022006 which is unparsable.

@dtertman sufficiently exotic timestamp formats require custom parsing routines. (Not saying that's the case for the original issue, but it could be.)

@cespare fair enough. The question then becomes whether _yyyy is "sufficiently exotic".

Proposed fix : Allow \ to indicate that the next character is not part of the example, but text. Submitter's pattern could then be written as 15:04\_20060102 and mine from above might even be workable as Mon\0\2Jan\0\22\0\22006

EDIT : Nope. This would break backwards compatibility with any mm\dd\yyyy pattern.

FYI, I have been bypassing this bug using this specification replacement method:

func bypassTimeParseBug(s string) string {
        // NB: Looks like there is a bug in Golang's time.Parse when handing format strings
        // with _2 in the format string. Here is a snippet that exhibits this issue:
        //     t, e := time.Parse("15:04_20060102", "14:38_20150618")
        // We replace underscores with space to bypass this bug.
        return strings.Replace(s, "_", " ", -1)
}

I would posit that the format I specified is not exotic at all. At least, I didn't invent it. It's the format used by Graphite to specify absolute timestamps.

Pretty much any change made is likely to break someone's time format string. But time format strings are probably almost always in ASCII. So would a unicode character that's unlikely to be part of a format string be considered as an escape character? Or _ could be special cased so that ‗ (U+2017; double low line) means a literal _.

I think _2006 should be parsed as _ followed by 2006, not as _2 followed by 006.
That is, there's no need for new API or notation here; just fix the current notation.

/cc @robpike

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

@rsc I was over thinking the issue, my bad. Please see my CL.