This is unfortunate. In order to fix this, we either:

1. implement JSON string decoding in the time package (a correct implementation is not trivial),
2. have the time package depend on the json package, or
3. move just the JSON string decoding logic from the json package into some internal package that both time and json can access.

As an aside: it was a mistake to implement UnmarshalJSON methods on time.Time, and there should only have been the UnmarshalText methods since those take in the unescaped string.

Would it be plausible for the JSON package to special-case time.Time, ignoring (time.Time).UnmarshalJSON in favor of a correct implementation?

This obviously doesn't scale to all types everywhere, but perhaps it would suffice for standard library types where we regret adding an UnmarshalJSON method.

Would it be plausible for the JSON package to special-case time.Time, ignoring (time.Time).UnmarshalJSON in favor of a correct implementation?

That's another option. One detriment is that it fails to detect cases of embedding:

type MyTime struct { time.Time }

Here MyTime forwards all methods of time.Time and then probably adds a few more. From the perspective of the json package, it cannot accurately tell if MyTime is promoting time.Time.{Marshal,Unmarshal}JSON or not. The best it can do is check that MyTime has an anonymous field of type time.Time, but reflect provides no way to tell if the UnmarshalJSON method is explicitly declared on the MyTime type (because perhaps they really did want different formatting) or was forwarded from time.Time.

It also wouldn't fix it for other implementations of json (and yaml?) decoders

I suspect YAML decoders will be fine because they will probably use the UnmarshalText methods, but who knows.

As an aside: it was a mistake to implement UnmarshalJSON methods on time.Time, and there should only have been the UnmarshalText methods since those take in the unescaped string.

For what it's worth, time.Time.UnmarshalJSON was added before UnmarshalText existed. It was one of the reasons that UnmarshalText was invented. See https://golang.org/s/go12encoding.

Crazy idea: The json package can try the UnmarshalJSON method first. If it errors, the JSON token is a string, and a UnmarshalText method exists, then try the UnmarshalText method.

This ensures backwards compatibility where UnmarshalJSON takes precedence over UnmarshalText. This should be mostly compatible as all it would ever do is convert a few error cases to non-errors (presumably all desirable behavior changes).

EDIT: This approach assumes that either UnmarshalJSON is side-effect-free in the event of an error OR UnmarshalText discards all pre-existing state on the receiver. If either is not true, then we can run into silent data corruption.

At least for time.Time, we know that it's the latter since unmarshal overwrites the entirety of the receiver value.

Make it a specific sentinel error returned by UnmarshalJSON, and it'll be entirely backwards compatible.