2019 file shows 1989 timestamps

[JuanIrache]

Hi, congratulations for the module. Really useful.

I have a file shot in 2019 where the records show timestamps from 1989, like "1989-12-31T00:00:06.000Z"

Could this be a problem in the parsing process? Or is the file corrupt in some way?

I can share the file privately if you can have a look at it. Or if you can provide instructions for debugging this I will follow them on my end.

Thank you.

[jimmykane]

Hey hi and thanks a lot for the good words. I have seen some cases of similar reports. Typically a parsing error from a binary would result to a completely wrong date. Do all timestamps have this wrong date ? Sometimes some services have this issue idk why exactly. Usually the service is the culprit.

…

On Mon, 15 Feb 2021, 22:16 Juan Irache, ***@***.***> wrote: Hi, congratulations for the module. Really useful. I have a file shot in 2019 where the records show timestamps from 1989, like "1989-12-31T00:00:06.000Z" Could this be a problem in the parsing process? Or is the file corrupt in some way? I can share the file privately if you can have a look at it. Or if you can provide instructions for debugging this I will follow them on my end. Thank you. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#25>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJVX43DHQVEQCFHDGZMYIDS7F6KJANCNFSM4XVIENNA> .

[JuanIrache]

Yes. All timestamps look like that

["1989-12-31T00:00:02.000Z","1989-12-31T00:00:03.000Z","1989-12-31T00:00:04.000Z", /* ... */"1989-12-31T09:02:40.000Z","1989-12-31T09:02:41.000Z","1989-12-31T09:02:42.000Z","1989-12-31T09:02:43.000Z","1989-12-31T09:02:44.000Z"]

Sorry, what is the service in this context?

I notice this other strange bit. See "local_timestamp"

  "activity": {
    "timestamp": "1989-12-31T09:02:45.000Z",
    "total_timer_time": 32563.611,
    "local_timestamp": "2126-02-06T06:28:15.000Z",
    "num_sessions": 1,
    "type": "manual",
    "event": "activity",
    "event_type": "stop"
  },

One strategy I'm considering for my implementation is comparing the timestamps with file_ids.time_created, which seems correct, and if the difference is big apply the necessary offset. But I'm not sure if time_created is based on GPS time and would therefore be trust-worthy or not.

Edit: I forgot. The timestamps look correct in the Virb Edit software, so there could be a way to find the necessary offset info, I guess.

Here's the rest of the parsed data (except records, laps and sessions for brevity and some private details) in case it helps:

{
  "protocolVersion": 16,
  "profileVersion": 2010,
  "file_creator": {
    "software_version": 480
  },
  "activity": {
    "timestamp": "1989-12-31T09:02:45.000Z",
    "total_timer_time": 32563.611,
    "local_timestamp": "2126-02-06T06:28:15.000Z",
    "num_sessions": 1,
    "type": "manual",
    "event": "activity",
    "event_type": "stop"
  },
  "records": [],
  "sessions": [],
  "laps": [],
  "lengths": [],
  "events": [
    {
      "timestamp": "1989-12-31T00:00:02.000Z",
      "data": 0,
      "event": "timer",
      "event_type": "start",
      "event_group": 0
    }
  ],
  "device_infos": [
    {
      "timestamp": "1989-12-31T00:00:02.000Z",
      "serial_number": 00000000000,
      "manufacturer": "garmin",
      "product": 2417,
      "software_version": 4.8,
      "device_index": 0,
      "source_type": "local"
    },
    {
      "timestamp": "1989-12-31T00:00:02.000Z",
      "manufacturer": "garmin",
      "product": 2417,
      "software_version": 4.8,
      "device_index": 1,
      "source_type": "local"
    },
    {
      "timestamp": "1989-12-31T00:00:06.000Z",
      "manufacturer": "garmin",
      "product": 3264,
      "software_version": 4.5,
      "device_index": 2,
      "device_type": 0,
      "source_type": "local"
    }
  ],
  "developer_data_ids": [],
  "field_descriptions": [],
  "hrv": [],
  "dive_gases": [],
  "course_points": [],
  "sports": [],
  "devices": [
    {
      "timestamp": "1989-12-31T00:00:02.000Z",
      "serial_number": 00000000000,
      "manufacturer": "garmin",
      "product": 2417,
      "software_version": 4.8,
      "device_index": 0,
      "source_type": "local"
    },
    {
      "timestamp": "1989-12-31T00:00:02.000Z",
      "manufacturer": "garmin",
      "product": 2417,
      "software_version": 4.8,
      "device_index": 1,
      "source_type": "local"
    },
    {
      "timestamp": "1989-12-31T00:00:06.000Z",
      "manufacturer": "garmin",
      "product": 3264,
      "software_version": 4.5,
      "device_index": 2,
      "device_type": 0,
      "source_type": "local"
    }
  ],
  "monitors": [],
  "stress": [],
  "file_ids": [
    {
      "serial_number": 00000000000,
      "time_created": "2019-08-18T05:18:14.000Z",
      "manufacturer": "garmin",
      "type": "activity"
    }
  ],
  "monitor_info": [],
  "definitions": []
}

[JuanIrache]

Hi @jimmykane

Any thoughts on this? Would the workaround I suggested make sense?

Thank you

[JuanIrache]

Just to report back, my workaround seems to produce good results:

comparing the timestamps with file_ids.time_created, (...) and if the difference is big apply the necessary offset.