Native value conversion for Protobuf Timestamp has surprising behavior with v0.11.1

[timostamm]

When a Protobuf message is evaluated, a google.protobuf.Timestamp field outside of the valid ranges raises an IllegalArgumentException.

The behavior is logical, but how can users determine that a Protobuf message is safe to evaluate? An invalid Timestamp serializes and parses without error, and I don't believe that there is an API to validate that a message contains only conforming Timestamp values in any OSS Protobuf implementation.

#820 adds a deprecation notice to the evaluateCanonicalTypesToNativeValues option with a note that the option will be removed. Are there perhaps any plans to consolidate the behavior between Protobuf implementations and CEL?

[l46kok]

We're discussing this issue internally. We are considering changing the spec to disallow timestamps outside the RFC 3339 range by default, but that requires more consideration. Broadly, the aim was to avoid surprises—like timestamp(Long.MAX) evaluating successfully, but timestamp(Long.MAX) - timestamp(0) causing an overflow error. We're separately considering to introduce a flag to allow for infinite timestamp ranges as a convenience, but that also requires some more thought in regards to portability.

For the time being, I think we should treat this as a regression, revert back to the original behavior as a start. i.e: treating timestamps as "dumb carriers" that do not validate on conversion, only validating if and when computation is performed on them.