Change all duration fields in the API to time.Duration

[bgrant0607]

We have a number of fields in the API that represent an integer number of seconds, such as TimeoutSeconds. We should push the units into the value instead, by using time.Duration. That would be similar to the approach used for resource quantities.

I don't consider this blocking for v1beta3, but seems like a worthwhile change to make in the future.

cc @lavalamp @smarterclayton

[thockin]

caution when using non-dumb-struct types in the API. For example, they can
not always be fuzzed or compared generically. See util.Time.

On Thu, Mar 26, 2015 at 1:55 PM, Brian Grant [email protected]
wrote:

We have a number of fields in the API that represent an integer number of
seconds, such as TimeoutSeconds. We should push the units into the value
instead, by using time.Duration. That would be similar to the approach used
for resource quantities.

I don't consider this blocking for v1beta3, but seems like a worthwhile
change to make in the future.

cc @lavalamp https://github.com/lavalamp @smarterclayton
https://github.com/smarterclayton

—
Reply to this email directly or view it on GitHub
#6013.

[lavalamp]

Yeah we'll have to make a wrapper type to make json encode/decode call Duration.String() and ParseDuration().

[lavalamp]

I filed golang/go#10275 on the off chance that we code get this working by default.

[smarterclayton]

And unfortunately when we do that JSON starts showing the field automatically even with omitempty because the JSON encoder has a structured list of types. So you get a lot of "foo": "", showing up. Definitely hit the limits of the JSON stdlib now.

----- Original Message -----

I filed golang/go#10275 on the off chance that we
code get this working by default.

---

Reply to this email directly or view it on GitHub:
#6013 (comment)

[smarterclayton]

We decided that we would not use duration because the encoding isn't stable. Closing this and we can reopen the discussion on the next time API field.