2

I have an application where an embedded device sets an internal timestamp each day from a server request. To make things simple the server returns time in Unix Epoch for example:

1602529759 = 10/12/2020 3:08:XX EST PM

These devices report that original timestamp back and usually it is correct. However every once in a while we will get a timestamp that takes place 17 years and a few days in the future. The datestamp always seems to relate to the correct value, but in 2037. For example if todays date is 10/12/2020 the date reported by the device will be 10/17/2037 (approx). I suspect the issue is related to a binary math issue and an overflowing of the integer (a UINT32_t). I would like to determine the cause of the issue buy my bigger priority is to gain an understanding of the problem so I can correct the improperly reported values in our database.

Any ideas what might be going on here?

Tanner Ewing
  • 337
  • 4
  • 18
  • I'd go either - if the time is far beyond expected, send the received time to the server and store it with computed value. Or, if you know timeframe when it happened, check access_log and find out request times and try to compute the values. Or simple brutal force - generate time for each second in month and check if it's computed correctly – KIIV Oct 12 '20 at 19:43
  • 3
    This does not seems to be an overflow problem but a bit error. `1602529759` is `5F84A9DF` in hexadecimal, for the same time and date in 2037 is `2138987359` (`7F7EB6DF`). It seems that for some reason, the `5F` became `7F`... – hcheung Oct 13 '20 at 01:51
  • @hcheung I think you are correct! I will have a look at how that plays out throughout the data. If you reply as an answer I will accept it – Tanner Ewing Oct 13 '20 at 14:59

0 Answers0