Datetime wrong on gpx generated file

[jmcdrone]

blackbox_decode genarate a gpx file with not corresponds to the correct timestamp from log.txt file. It always some minutes above the correct time. Like 10, 8 or 3 minutes above correct time. Another observation: The osd displays the correct datetime!!!! :(

[stronnag]

It's worse that that (misinterpreting the time offset); it also ignores the time zone and pretends everything is UTC.

[jmcdrone]

//------------------------gpx file datetime fixed!----------------------------

char format_gps_timez(flightLog_t log, int64_t microseconds, char tbuf, size_t tbufsz) { char strTime[100]; sprintf(strTime, "%ld", log->sysConfig.logStartTime.tv_sec 1000000 + (microseconds-log->firsttime)); long dTime; sscanf(strTime, "%10ld", &dTime); time_t unix_timestamp = dTime; struct tm *tm_info; tm_info = gmtime(&unix_timestamp); strftime(tbuf, tbufsz, "%Y-%m-%d %H:%M:%S", tm_info);

return tbuf;

//---------------------------------------------------------------------- works for Windows. *At time ---‐--

[stronnag]

It is already fixed in #71 without using strings (and actually works, unlike the above).

[jmcdrone]

Now you get the idea! ;) Better would be to know how to work with 16 digits timestamp in C. I couldn't find this. Please, let me now if you can.

[stronnag]

I'm not sure what idea you are taking about, or the need to work with 16 digits. Using strings a waste of time, inefficient and leads to all sorts of bugs.

• #71 works correctly across all targets and architectures (unlike your proposal) • #71 is efficient (no unnecessary string functions) • Your proposal fails to compile on Windows, MacOS and any 32bit system (-Wall -Werror) • Your proposal (compiled without -Werror on ia32) gives grossly incorrect results due to naive integer overflow. • Your proposal fails to generate a valid xsd:datetime with decimal seconds and time zone.

But thanks for raising the initial issue and testing.