function/stdlib: Use local RFC3339 parser #152
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.