duration() allows inf / -inf values

[jsannemo]

The string to Duration conversion accepts inf and -inf (since Abseil does) which produces internal durations that are not valid CEL durations.

[kyessenov]

@JimLarson I checked the spec, and it seems that only the format (+|-|)\d+s is a valid input to duration. Is it the case? Also, for reverse, how do we handle nanos?

[kyessenov]

@JimLarson gentle ping: is it correct to assume that duration() only takes round seconds as input?

[JimLarson]

Yes, assume that duration(string) --> g.p.duration only takes a signed int followed by "s". There's a request/proposal somewhere for a more flexible format with different units (y/d/h/m), and possibly even mixed units ("3d4h").

We're in the process of defining a set of duration conversion functions duration('120s').toMinutes() ==> 2, and it would be reasonable to add functions for "fromMinutes/Hours/...", but we don't have a proposal yet.

You might be able to create a literal google.protobuf.Duration message, but I we might have intentionally made that an "opaque" type where the proto representation is supposed to be an implementation detail and you're not supposed to create message literals or extract fields. I could be wrong on this - I tried writing a conformance test but it failed RPC'ing the results back to the driver, not an evaluation failure, so it might work even if we don't intend it to.

To get a duration with nanos, you can either bind such a duration message to a cel variable, or (utter hack warning) you can create timestamp literals with nanosecond precision, then take a difference of them to get a duration.

If you have an immediate need for a more flexible format for the duration() function, let us know what features you'd need.

[kyessenov]

Thanks for the response. In the context of latency measurements, I think microseconds and milliseconds would be nice to support. A second is a long time in that world.

[JimLarson]

Sounds good. Since an expanded duration notation would affect all CEL implementations, I'm going to refer you to google/cel-spec#138 for any further discussion along those lines and you can keep this issue just for fixing the +/- inf input as described in the original comment.