The Go time package's interpretation of RFC3339 has historically been too liberal to properly meet the specification due to reliance on the "parse by example" approach taken by time.Parse.
There was a custom strict RFC3339 parser added during the Go 1.20 development period but that was removed just before release due to backward compatibility concerns.
Since cty's goal is to only accept valid RFC3339 and its use of the Go standard library to achieve that was always an implementation detail, here we'll now just inline a slightly similified version of the strict RFC3339 parser that was briefly in stdlib and use that.
Although a variation of this strict parser will probably land in Go stdlib again eventually, the goal here is to decouple cty's behavior from the Go stdlib behavior so it will be consistent regardless of what version of Go the application was compiled with and regardless of any GODEBUG flags the Go team might add to help mitigate compatibility problems in other applications.
Background details on the Go stdlib changes that prompted this are over in golang/go#57912.
Note: If anyone was previously passing slightly-invalid RFC3339 strings to the formatdate function, or to any other function which expects an RFC3339 timestamp, those will now be rejected as invalid and will need to be fixed. The out-of-spec parsing was a defect rather than a feature and so I don't consider this to be a breaking change to the contract of those functions.
The Go
timepackage's interpretation of RFC3339 has historically been too liberal to properly meet the specification due to reliance on the "parse by example" approach taken by time.Parse.There was a custom strict RFC3339 parser added during the Go 1.20 development period but that was removed just before release due to backward compatibility concerns.
Since cty's goal is to only accept valid RFC3339 and its use of the Go standard library to achieve that was always an implementation detail, here we'll now just inline a slightly similified version of the strict RFC3339 parser that was briefly in stdlib and use that.
Although a variation of this strict parser will probably land in Go stdlib again eventually, the goal here is to decouple cty's behavior from the Go stdlib behavior so it will be consistent regardless of what version of Go the application was compiled with and regardless of any
GODEBUGflags the Go team might add to help mitigate compatibility problems in other applications.Background details on the Go stdlib changes that prompted this are over in golang/go#57912.
Note: If anyone was previously passing slightly-invalid RFC3339 strings to the
formatdatefunction, or to any other function which expects an RFC3339 timestamp, those will now be rejected as invalid and will need to be fixed. The out-of-spec parsing was a defect rather than a feature and so I don't consider this to be a breaking change to the contract of those functions.