Repository navigation
Native value conversion for Protobuf Timestamp has surprising behavior with v0.11.1 #890
Description
Activity
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.
Reacted by Timo Stamm- added 8 commits that reference this issue
on Dec 16, 2025
When a Protobuf message is evaluated, a
google.protobuf.Timestampfield 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
evaluateCanonicalTypesToNativeValuesoption with a note that the option will be removed. Are there perhaps any plans to consolidate the behavior between Protobuf implementations and CEL?