Skip to content

Add a few overloaded methods for eval & trace - #501

Closed
copybara-service[bot] wants to merge 0 commit into
mainfrom
test_699122409
Closed

copybara-service[bot] wants to merge 0 commit into
mainfrom
test_699122409

Conversation

@copybara-service

@copybara-service copybara-service Bot commented Nov 22, 2024 •

Copy link
Copy Markdown
Contributor

Add a few overloaded methods for eval & trace

@copybara-service
copybara-service Bot force-pushed the test_699122409 branch 2 times, most recently from 39ab5b6 to 1f65d7e Compare November 25, 2024 07:36
@copybara-service copybara-service Bot changed the title Add a few overlaoded methods for eval & trace Add a few overloaded methods for eval & trace Nov 25, 2024
@copybara-service
copybara-service Bot force-pushed the test_699122409 branch 7 times, most recently from 16eed04 to 96163dd Compare November 26, 2024 11:56
@copybara-service copybara-service Bot closed this Nov 26, 2024
@copybara-service
copybara-service Bot deleted the test_699122409 branch November 26, 2024 12:05
copybara-service Bot pushed a commit that referenced this pull request Oct 30, 2026
CEL specification PR #501 widens valid CEL durations from roughly ±290 years (64-bit signed nanoseconds) to the full `google.protobuf.Duration` range (±10,000 years, -315,576,000,000.999999999s to +315,576,000,000.999999999s) so every valid `Timestamp` difference is representable as a CEL duration, and rejects out-of-range `google.protobuf.Duration` and `google.protobuf.Timestamp` message literals at construction.

Update duration validation, timestamp and duration arithmetic, `timestamp(int)` epoch-second bounds, protobuf message literal construction, and Z3 verifier bounds and witness formatting to enforce full protobuf duration and RFC 3339 timestamp bounds while preserving unvalidated field selection on existing protobuf messages. Replace `threeten-extra` duration string parsing with a zero-allocation Go `time.ParseDuration`-compatible parser supporting the ±10,000-year range (removing the `org.threeten:threeten-extra` dependency), deprecate `CelOptions.Builder.enableTimestampOverflowCheck` as a no-op, and re-enable the skipped duration and timestamp spec conformance suites.

PiperOrigin-RevId: 1010820757
copybara-service Bot pushed a commit that referenced this pull request Oct 31, 2026
CEL specification PR #501 widens valid CEL durations from roughly ±290 years (64-bit signed nanoseconds) to the full `google.protobuf.Duration` range (±10,000 years, -315,576,000,000.999999999s to +315,576,000,000.999999999s) so every valid `Timestamp` difference is representable as a CEL duration, and rejects out-of-range `google.protobuf.Duration` and `google.protobuf.Timestamp` message literals at construction.

Update duration validation, timestamp and duration arithmetic, `timestamp(int)` epoch-second bounds, protobuf message literal construction, and Z3 verifier bounds and witness formatting to enforce full protobuf duration and RFC 3339 timestamp bounds while preserving unvalidated field selection on existing protobuf messages. Replace `threeten-extra` duration string parsing with a zero-allocation Go `time.ParseDuration`-compatible parser supporting the ±10,000-year range (removing the `org.threeten:threeten-extra` dependency), deprecate `CelOptions.Builder.enableTimestampOverflowCheck` as a no-op, and re-enable the skipped duration and timestamp spec conformance suites.

PiperOrigin-RevId: 1010820757
copybara-service Bot pushed a commit that referenced this pull request Oct 31, 2026
CEL specification PR #501 widens valid CEL durations from roughly ±290 years (64-bit signed nanoseconds) to the full `google.protobuf.Duration` range (±10,000 years, -315,576,000,000.999999999s to +315,576,000,000.999999999s) so every difference between valid `Timestamp` values is representable as a CEL duration.

Update duration bounds checking, timestamp and duration arithmetic, and `timestamp(int)` epoch-second validation across both native `java.time` and protobuf runtime representations. Replace `threeten-extra` duration parsing with a zero-allocation Go `time.ParseDuration`-compatible parser supporting the ±10,000-year range (removing the `org.threeten:threeten-extra` dependency), deprecate `CelOptions.Builder.enableTimestampOverflowCheck` as a no-op, and enable the widened duration conformance tests.

PiperOrigin-RevId: 1010820757
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants