> On Apr 8, 2016, at 6:11 AM, Christopher Collins <[email protected]> wrote: > >> 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. >
+1. That was the original thought. Underlying counters may not be at that precision- but that doesn't mean you can't store it as microseconds > Chris > >> >> Regards, >> Vipul Rahane >> >>> On Apr 7, 2016, at 10:02 PM, Justin Mclean <[email protected]> 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 >>
