## Forums

#### Guest

Welcome Guest, posting in this forum require registration.

 Pages: [1]
Author Topic: Track Recorder PID Log
gyorston
Member
Posts: 15
 Track Recorder PID Logon: November 23, 2020 (GMT)

I am trying to get interpret the PID Log files that show up in the Track recorder folders – the information is great. What I would like to interpret is the time value – it is a huge number (e.g. 1605826471697) and varies by an average value of around 100.Does anyone know how that Time value relates to real time?

moreause
Member
Posts: 642
 Re: Track Recorder PID Logon: November 24, 2020 (GMT)

in my case i’m seeing to normal time

but could be a case of excel cell format issue
excel time is started somewhere in january 1900 and increment

if you use a number format you see and big number if you change it to date or time it ok

ps in my case they show as they should

GPS Time Device Time
Sat Oct 05 19:09:23 HAE 2013 05-oct.-2013 21:13:10.729

just for fun try to export the file just to see if there is some change

Tux
Member
Posts: 12
 Re: Track Recorder PID Logon: November 25, 2020 (GMT)

It’s undoubtedly the time in milliseconds since the Unix epoch (01 Jan 1970 00:00:00 UTC). Decoded, your example would be “19 Nov 2020 22:54:31 UTC”. Convert to your preferred time zone, of course.

gyorston
Member
Posts: 15
 Re: Track Recorder PID Logon: November 25, 2020 (GMT)

Thanks for the feedback – will give alternate formatting a try

gyorston
Member
Posts: 15
 Re: Track Recorder PID Logon: November 25, 2020 (GMT)

Hey Tux, what was your formula to decode?

gyorston
Member
Posts: 15
 Re: Track Recorder PID Logon: November 25, 2020 (GMT)

I worked it out – thanks for the clue. Convert using a formula like this : =A2/1000/86400+25569 where A2 is the Unix Epoch date, 86400 represents seconds in a day, 1000 sorts out the milliseconds and 25569 adds the start date (01/01/1970). Then all you need to do is adjust for your timezone

Tux
Member
Posts: 12
 Re: Track Recorder PID Logon: November 25, 2020 (GMT)

Glad to hear you worked it out, but I don’t understand how your formula works. For example, 25569 days is roughly 70 years, not 50 (2020-1970). But who am I to question it if it solves your problem?

I will say that any formula for converting ‘seconds since Unix epoch’ to today’s date/time which doesn’t account for leap years will not be robust enough to use in the general case.

How are you doing the computation (spreadsheet, program [what language])? The time in seconds (not milliseconds) since the Unix epoch is a very common thing in the computing world and there should be a function to do the calculation for you — in both directions, in fact. No sense re-inventing the wheel!

As to how I did the conversion, it’s a trivial 1-line command in Linux:

```> TZ='UTC' date -d @1605826471
Thu Nov 19 22:54:31 UTC 2020```

If I wanted it in my local timezone, I’d just leave off the leading “TZ=’UTC'” part.

But of course, when doing it programmatically, I use the various ‘time’ library’s functions.

 Pages: [1]
WP-Forum by: Fredrik Fahlstad, Version: 2.4