I want to use this opportunity to flog one of my favorite topics: whether or not to store epoch time using variable-length numbers in protobuf. TL;DR: never do

I want to use this opportunity to flog one of my favorite topics: whether or not to store epoch time using variable-length numbers in protobuf. TL;DR: never do this If you are storing the epoch offset in seconds, you could store it as int32 or fixed32 (assuming the range is adequate for your application). But int32 will need 5 bytes, while the fixed32 field would only use 4. So you never save space and always spend time using int32. Similarly, if you are storing the offset as nanoseconds, never use int64. Except for a few years on either side of the epoch, the offset is always optimal in a fixed64. int64 will tend to be 9 bytes. Fixed64 nanoseconds has adequate range for most applications. You'll note that the "well-known" google.protobuf.Timestamp message commits both of these errors. It stores the seconds part as a varint, which will usually be at least 5 bytes when it could have been 4, and it stores the nanoseconds separately in an int32, even though this is more or less an RNG and is virtually guaranteed to need 5 bytes, if present. So nobody should use that protobuf. Thus ends this episode of my irregular advice on how to represent the time.