TestFormatDate fails with upcoming Go 1.20 release about go-cty HOT 5 CLOSED

Thanks for letting me know about this, @ianlancetaylor.

I'm general I try to avoid directly exposing Go standard library error messages in this library's interface because the errors here often end up being in the UI of calling applications where the user isn't expected to be aware that Go is involved, and those applications depend on these error messages being of suitable quality for use in that context.

Reviewing this code it looks like this is not directly returning a Go library error message but it is reinterpreting a time.ParseError into a derived message in a way that depends on how the time.Parse function classified each invalid token. Therefore although it's not depending on the error string exactly, it is depending on the data that the error string would have been built from, and so has improved in the same way that the underlying Go library error has.

(If I recall correctly, the exact string the time.ParseError type was producing was something like "cannot use 2-12-02T00:00:00Z as 2016", which is understandable only if you are familiar with the example timestamp the time package uses, and hence I wrote this function which "knows" that example timestamp and tries to translate the error into something more intelligible.)

I'll ponder how best to solve this after the US Thanksgiving holiday. I recall that there is now an RFC3339-specific parser in the time.Time UnmarshalText implementation, and it probably makes sense to use that instead here anyway since the intent is to only support RFC3339 as input, but I may need to copy it into this codebase for now to avoid imposing a Go 1.20 requirement immediately. Doing that would also have the advantage of freezing the error handling in here so that it won't be affected by future stdlib changes.

from go-cty.

Ping. Any update?

from go-cty.