GPSBabel
xml dateTimes without timezones should be local, not UTC
XML Schema Part 2: Datatypes Second Edition 3.2.7 refers to untimezoned dateTime values as "Local".
Correcting this results in 2 test failures. These result from the change in interpretation of untimezoned elements in:
- reference/track/fitwrite-track.gpx contains untimezoned time elements.
- reference/gc/GC7FA4.gpx contains untimezoned groundspeak:date elements. I don't believe there is a grounspeak schema, so we are only assuming they use the dateTime datatype.
While we can patch up xml_parse_time to correct the above issue, we can also consider reducing it to
return QDateTime::fromString(dateTimeString, Qt::ISODateWithMs);
xsd:dateTime is derived from ISO8601, and using the built in Qt ISO conversion is likely sufficient.
The 1.1 gpx xsd does have a comment saying times are in UTC and conform to ISO 8601. To conform it would seem to require that the times are timezoned with 'Z', '+00:00', '+0000' or '+00'. The 1.0 gpx xsd does not include this comment.
Creation/modification timestamp for element. 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.
I was going to cite that as an issue. It was intended for GPX 1.0 to say that, too.
It was felt that in the GPS domain, that there rarely was a sensible concept of 'localtime' (if your bike ride ran across the state/TZ border, you clearly didn't arrive an hour after you departed) and that most times would be in GPS time or UTC. Additionally, GPS receivers of the era could easily compute UTC from GPS time (there's a frame from the SVs that announces the offset) while they lacked access to the fleeting TZ data, which can change from even year to year. AZ doesn't do DST, over time this county or that moves from this TZ to that TZ or boycotts DST or DST start/end dates move or whatever.
We, the GPX authors, decided to buck XML convention and mandate that all GPX times be considered UTC. I think in 1.0, especially, we lacked the official wording to declare it as part of the specification.
As a discussion point that came up, we acknowledged that a time without a date also doesn't have the information to handle sensibly anyway. Was that date before or after the TZ change? If it was the third week of March, was it before or after the year that the start of DST moved? It was just a messy situation. (It still *is *messy, but that's the mess we chose.)
I'd be hip with that same logic applying to times without TZs in our handlers, though if you feel strongly otherwise, I won't wrestle you over it. The [1] person doing the work gets 51% of the votes.
I'll also add that historically, users may challenge us on the 10-14 seconds of UTC vs GPS time and care deeply about times within a trk/trkseg, we've often gotten away with murder or mismanaging time zones in timestamps inside tracks. It's been a bit surprising to me when we add a TZ instead of subtract it or something and nobody will notice for the longest time.
RJL
[1] "Qualified", as is obviously true here. I'm just throwing that in to prevent some other contributor from throwing my words at me.
On Thu, May 11, 2023 at 8:31 AM tsteven4 @.***> wrote:
The 1.1 gpx xsd does have a comment saying times are in UTC and conform to ISO 8601. To conform it would seem to require that the times are timezoned with 'Z', '+00:00', '+0000' or '+00'. The 1.0 gpx xsd does not include this comment.
Creation/modification timestamp for element. 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.— Reply to this email directly, view it on GitHub https://github.com/GPSBabel/gpsbabel/issues/1104#issuecomment-1544017641, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD35RT7Y6GL53STYBYHTXFTS3FANCNFSM6AAAAAAX6DRP24 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
So perhaps we want gpx time elements to be interpreted as UTC if they are untimezoned (as we do). But groundspeak:date elements and other readers (unicsv, xcsv, osm, kml, grtrnctr, html, text) are using xml_parse_time from gpx.cc and getting this unusual behavior. In the case of xcsv replacing the call with QDateTime::fromString(...,Qt::ISODateWithMs) seems in agreement with our documentation for ISO_TIME, ISO_TIME_MS. Our unicsv documentation doesn't even mention that the "date" and "time" keywords can be modified with "iso", but the same substitution seems reasonable. I think html and text are home grown formats and we can do whatever we want. Which leaves osm, kml and gtrnctr.
On Thu, May 11, 2023 at 3:11 PM tsteven4 @.***> wrote:
So perhaps we want gpx time elements to be interpreted as UTC if they are untimezoned (as we do). But groundspeak:date elements and other readers (unicsv, xcsv, osm, kml, grtrnctr, html, text) are using xml_parse_time from gpx.cc and getting this unusual behavior. In the
I'm unconvinced anyone cares about groundspeak:date, but I may be thinking of another tag. There was a time that xml_parse_time() had a second argument to identify which behaviour was wanted.
I think html and text are home grown formats and we can do whatever we
want.
Confirmed. Those are meant to be read by humans...originally on a PDA or a (gasp) printout.
Which leaves osm, kml and gtrnctr
Can those become fromString() and be OK?
