Switch To Human Readable Time Values

[bonedaddy]

• Use human-readable time values in places where we rely on time.Duration

[xiegeo]

What form will this take? I don't the data defined over the wire needs to change, just how it is displayed.

[bonedaddy]

Replace the int32 in the protocol buffer messages with a string value and use valid time.Duration strings like 1h, 1m, etc... that way we can do a time.ParseDuration.

Part of the issue with using time.ParseDuration before creating the message, and keeping the wire type as int32 is that time.Duration is technically a int64 value, but if the protocol buffer messages need to be used on or sent from 32bit devices to 64bit devices, and vice-versa, there might be some data loss.

By using the string type, it makes it easy since 32-bit and 64-bit devices can interchangeably deal with 1h and not suffer any loss of data due to encoding like big/little edian.

[xiegeo]

I agree the wire type should not be int32, but the downside to using time.ParseDuration is that it may not supported in other languages.

I think we can either switch to int64 or use google.protobuf.Duration.

Personally, I also like how Obj-C does duration with seconds in a float64.

[bonedaddy]

We actually aren't using time.Duration directly we're using the "semantics" which will work in every language because it's a string. So if someone wants to specify a 1hr timeout, they would simply give "1h".

Your link looks really interesting and cross-language friendly, I'll check that out.

[xiegeo]

If nothing else needs to read the value programically. Then that's a good idea.

[bonedaddy]

If nothing else needs to read the value programically. Then that's a good idea.

The only "thing" that should be reading the value programatically is TemporalX, which since it's Golang can handle the time conversion.