You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a number of places in the English specs that use u64 as timestamp or duration fields, but with the unit unspecified. One would have to look into the protobuf definitions and the Go code in ibc-go to figure out that the proper unit is in nanoseconds. This can easily cause misinterpretation, and cause the field to be processed in incorrect units such as seconds. (informalsystems/hermes#927)
We should at least clarify in the specs that the relevant u64 fields are in nanoseconds unit. Or if breaking change is possible, we should instead follow Tendermint and use Google.Protobuf.WellKnownTypes.Timestamp and Google.Protobuf.WellKnownTypes.Duration to encode timestamp and duration fields.
The text was updated successfully, but these errors were encountered:
There are a number of places in the English specs that use
u64
as timestamp or duration fields, but with the unit unspecified. One would have to look into the protobuf definitions and the Go code inibc-go
to figure out that the proper unit is in nanoseconds. This can easily cause misinterpretation, and cause the field to be processed in incorrect units such as seconds. (informalsystems/hermes#927)We should at least clarify in the specs that the relevant
u64
fields are in nanoseconds unit. Or if breaking change is possible, we should instead follow Tendermint and useGoogle.Protobuf.WellKnownTypes.Timestamp
andGoogle.Protobuf.WellKnownTypes.Duration
to encode timestamp and duration fields.The text was updated successfully, but these errors were encountered: