On Thu, Apr 07, 2016 at 10:33:26PM -0700, Vipul Rahane wrote: > Hello, > > I agree with your statement. We do not know on what kind of devices > Mynewt would be ported to. Sleepy devices which are meant to work for > 20 years running on a single coin cell battery will rollover the time > stamp in 2038. We want to be able to take care of such a situation. > While there are other solutions which can be implemented that are more > efficient, keeping it as simple as possible is better from an end to > end perspective as these logs would be used by applications to > understand the state of the devices. > > I was planning on storing microseconds because the OS currently > populates OS time in seconds and microseconds. For microseconds we do > require 32 bits. I agree for milliseconds 16 bits are enough but > higher resolution is always better.
I think 12 bytes of time is more than necessary. A few notes: * A single 64-bit microsecond counter allows for 584942 years before rollover. * A single 32-bit second counter won't actually roll over until 2106 (the 2038 issue only applies to signed 32-bit timestamps). If we want microsecond precision, I would just go with a single 64-bit counter. Otherwise, 32 bits of seconds is sufficient in my opinion. Chris > > Regards, > Vipul Rahane > > > On Apr 7, 2016, at 10:02 PM, Justin Mclean <justinmcl...@me.com> wrote: > > > > HI, > > > >> I am going to change the log structure so that it stores both(UTC > >> timestamp in seconds - 64 bit, Microseconds since last second - 32 bit) > > > > NO objection, but just out of interest why 64 bit for seconds (when 32 bit > > of seconds = 60+ years and good until 2038) and 32 bits for milliseconds > > when 16 bits will do? See also [1] > > > > Thanks, > > Justin > > > > 1. https://en.wikipedia.org/wiki/Year_2038_problem#Solutions > > >
