GPSBabel / gpsbabel

GPSBabel: convert, manipulate, and transfer data from GPS programs or GPS receivers. Open Source and supported on MacOS, Windows, Linux, and more. Pointy clicky GUI or a command line version...
https://www.gpsbabel.org
GNU General Public License v2.0
475 stars 127 forks source link

xml_parse_time interprets untimezoned times as UTC #282

Open tsteven4 opened 5 years ago

tsteven4 commented 5 years ago

https://www.w3.org/TR/2004/PER-xmlschema-2-20040318/datatypes.html#dateTime states

"Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority; but xml_parse_time (in gpx.cc) interprets untimezoned times as UTC.

For gpx, the time element is from this schema, i.e. xsd:time.

ISO8601 is the same:

Time zones in ISO 8601 are represented as local time (with the location unspecified), as UTC, or as an offset from UTC.

If we conform the xml schema and ISO 8601 we have one unicsv test case that fails. And 62 lines of code can be replaced by one: return QDateTime::fromString(dateTimeString, Qt::ISODateWithMs).toUTC();

robertlipe commented 5 years ago

That was contentious in the early days of GPX.

https://www.topografix.com/gpx_manual.asp#time

Date and time in are in Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation. Fractional seconds are allowed for millisecond timing in tracklogs.

It was the intention that time always be represented as UTC (sensible) but then it punted out to ISO 8601 which says that without that trailing "Z", it's a local time - which is almost never actually useful in a GPX file because your GPX track may cross a time zone or whatever. This is the reason we have the code that evolved into QDateTime::fromString.

At least that's my memory of the horror that became xml_parse_time()

I see only one example (both GC's come from Groundspeak) of GPXes that write in local time anyway and that code is of an era where they got time zones wrong in a LOT of places. I just pulled that exact waypoint out of their database and see MUCH more sensible dates from the geocaching site now:

The current GPX is better several ways. Maybe we're working around a practice that doesn't matter any more...

[image: Screen Shot 2018-12-09 at 4.52.27 PM.png] If we can safely assume a Z in time and empty the body of that horror of a function, I'll regenerate those two GC files.

RJL

On Fri, Dec 7, 2018 at 6:25 PM tsteven4 notifications@github.com wrote:

https://www.w3.org/TR/2004/PER-xmlschema-2-20040318/datatypes.html#dateTime states

"Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority; but xml_parse_time (in gpx.cc) interprets untimezoned times as UTC.

For gpx, the time element is from this schema, i.e. xsd:time.

ISO8601 is the same:

Time zones in ISO 8601 are represented as local time (with the location unspecified), as UTC, or as an offset from UTC.

If we conform the xml schema and ISO 8601 we have one unicsv test case that fails. And 62 lines of code can be replaced by one: return QDateTime::fromString(dateTimeString, Qt::ISODateWithMs).toUTC();

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gpsbabel/gpsbabel/issues/282, or mute the thread https://github.com/notifications/unsubscribe-auth/AIUh70TL9Ivn50NSGsV9cnPKD2HZjp-qks5u2wcLgaJpZM4ZJWd6 .