Running the benchmark for 10s I get 4.6 gigs of memory allocated -- I would love for the compiler to optimize away the generation of this error at all (if it's unread by the application), or alternatively if there was a ParseWithoutError() type method that would lessen memory usages.

https://go.dev/play/p/M9swxO5s-1R

This is a valid request but it's an unusual one. I want to set expectations that this will be difficult to fix and we are unlikely to do anything any time soon. For your immediate needs I would recommend copying the code in time/format.go to write your own format validity checker.

Related Issues

• time.String produces garbage out for time.Parse (garbage in) #17254 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Hi @mzimmerman, FWIW, I've encountered this exact scenario before. As Ian said, it probably wouldn't be too bad to just copy and tweak the code from the time package.

Another approach I've used (in a different language) is to pair each time format with a corresponding regex that first identifies candidate matches prior to attempting a full time parse, which cuts down quite a bit how often the full time parse fails.

So if we were to update a portion of your benchmark, it could be something like (playground link):

	formats := []pattern{
		{rePattern: `^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}-\d{4}$`, format: "2006-01-02T15:04:05.999-0700"},
		{rePattern: `^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3} -\d{4}$`, format: "2006-01-02T15:04:05.999 -0700"},
		{rePattern: `^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}$`, format: "2006-01-02T15:04:05.999"},
	}

with sample results:

       │  original   │      check-regexp-first           │
       │   sec/op    │   sec/op     vs base               │
Time-4   6.650m ± 5%   2.033m ± 3%  -69.43% (p=0.002 n=6)

       │  original   │      check-regexp-first           │
       │     B/op     │     B/op      vs base                │
Time-4   5.951Mi ± 0%   0.000Mi ± 0%  -100.00% (p=0.002 n=6)

Go doesn't have the fastest regex engine out there, but it's reasonable, and it usually would be faster than allocating errors.

And of course, you could an even lighter first check, like a string contains check or check specific offsets for specific literals, etc.

That said, maybe I misunderstood your situation or maybe that doesn't otherwise help.

@ianlancetaylor Thank you for the response. Years ago when I came to Go, I was initially frustrated with the io.Reader/io.Writer interface, but I see the wisdom in it now in that it doesn't require any allocations. Being that those are potentially heavy memory areas, the design really makes sense. I thought the same thing (sort of) could be applied to the time package. Only allocating as minimal memory as is required to get the job done. I get that this isn't high priority and is niche.

@thepudds You're spot on. I've thought about doing similar, like comparing length, but that breaks down when hours/minutes/days/months can be one (or two) digits. Also, January and March are different also. The simplest (for me) is if the time package supported what I want :) A colleague already started to bring it in and modify the time package and I think that's what we'll end up doing, cause at the end of the day the time package is doing some of those same string comparisons again, just at a later time. I don't want to have to do it twice if I don't have to anyway.

You might also want to look at other implementations, like https://pkg.go.dev/github.com/araddon/dateparse

I'm not sure if there's anything to do here? ignoring the error is unusual in go code, and you're better off using a more flexible parser anyway.

given that it's a ParseError, it seems unavoidable.
Changing it to sentinel error is likely to be considered a breaking change, and less helpful to most programs.
https://pkg.go.dev/time#ParseError