3 ms·

Does anyone have the actual technical details of why this is?

• matthavener 17y ago
  My guess is that they're measuring time in milliseconds stored in a 32-bit signed integer and its overflowing to negative after 24.5 days (which is approx 2^31 milliseconds http://www.google.com/search?q=2^31+milliseconds+to+days http://www.google.com/search?q=2^31+milliseconds+to+days )
  • mikeryan 17y ago
    Ya I've run into this before where we started an ms counter at 0 and after 24 days it would overflow. Pain in the ass to catch....
  • ars 17y ago
    A simple overflow would not matter though, unless you were taking a picture exactly when it overflows. I bet it's a loss of accuracy when the timestamp gets large, and they start to do math on it. That means right after the 24.5 day cycle it will be great, and will get worse and worse till the end of the cycle. Personally I think that's the funniest bug ever.
• lacker 17y ago
  it is related to 24.5 days = 2^31 milliseconds. however it's not an overflow, it's a bug with sign extension when casting from uint32 -> int32 -> int64 -> uint64, instead of directly uint32 -> uint64. those operations are equivalent whenever the most significant bit of the uint32 is a 0, but orders of magnitude different when the most significant bit is a 1. so that explains why the bug turns off after 24.5 days and then turns back on after another 24.5 days. if this doesn't make any sense to you, check out this wikipedia page: http://en.wikipedia.org/wiki/Sign_extension http://en.wikipedia.org/wiki/Sign_extension the lesson is, be very careful when casting between signed and unsigned ints.