You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Native value conversion for Protobuf Timestamp has surprising behavior with v0.11.1 #890
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?
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.
Activity
l46kok commentedon Dec 12, 2025
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, buttimestamp(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.
Restore timestamp conversion behavior to allow ranges outside RFC3339
Restore timestamp conversion behavior to allow ranges outside RFC3339
Restore the behavior for protobuf timestamp/duration field values to …
Restore the behavior for protobuf timestamp/duration field values to …
Restore the behavior for protobuf timestamp/duration field values to …
Restore the behavior for protobuf timestamp/duration field values to …
Restore the behavior for protobuf timestamp/duration field values to …
Restore the behavior for protobuf timestamp/duration field values to …