(This came up when discussing the SBD55 message definition)
The SBD52 message uses float for some fields that are int32 in later messages; we might want to go back and change this for increased precision.
Example in python:
time.time()
1776472987.8170867
np.float32(time.time())
1776473000.0
It looks like if you serialize timestamps (from the last few years) as a float then deserialize as an int, you'll get a timestamp that's too old to be valid, and that's the check for whether to deserialize as a float instead to maintain backwards compatibility.
I suspect something similar could work for lat/lon, but haven't looked into it in any detail.
(This came up when discussing the SBD55 message definition)
The SBD52 message uses float for some fields that are int32 in later messages; we might want to go back and change this for increased precision.
Example in python:
It looks like if you serialize timestamps (from the last few years) as a float then deserialize as an int, you'll get a timestamp that's too old to be valid, and that's the check for whether to deserialize as a float instead to maintain backwards compatibility.
I suspect something similar could work for lat/lon, but haven't looked into it in any detail.