Opened 8 years ago

Closed 8 years ago

#3753 closed defect (invalid)

gpx upload fails is there are milliseconds in the time field

Reported by: sly Owned by: Tom Hughes
Priority: minor Milestone:
Component: website Version:
Keywords: Cc: sly


A gpx file containing a track with trackpoints like this one :

<trkpt lat="45.519491" lon="6.110975"> <ele>323.000000</ele> <time>2011-05-07T11:02:42,211Z</time> </trkpt>

result in an import failure with : "At least 75% of the trackpoints lacked a <time> tag."

The cause of the problem is the milliseconds (here the ,211 additions)

Of course, in the osm context milliseconds are irrelevant, but since it is supported by the gpx specs

(Element: time

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.)

some gpx generator might add millisecond and cause the gpx import to fail.

Change History (5)

comment:1 Changed 8 years ago by sly

This bug looks close to this one :

However, if I read correctly the ISO 8601 specification for date and time representation, a comma "," is supposed as a separator between seconds and miliseconds and not a dot "."

comment:2 Changed 8 years ago by sly

Cc: sly added

comment:3 Changed 8 years ago by Tom Hughes

ISO 8601 is not strictly relevant...

The GPX spec says the field should conform to xsd:datetime, which is only "inspired by" 8601.

That said, it does appear to allow fractional seconds. It appears to require '.' as the separator though:

comment:4 Changed 8 years ago by sly

whooops, looks like I missread the ISO 8601, milliseconds/seconds separator should be a dot

(whoops again, I tried to mark this bug as invalid but you were commenting on it)

comment:5 Changed 8 years ago by sly

Resolution: invalid
Status: newclosed

I'm closing this bug because my remark is not valid, my bad

Note: See TracTickets for help on using tickets.