time parsing

[KaiVolland]

Hey Tomo,

first of all: great work!

I think the time-parsing should be a little smarter. I'm getting "None" for every time that has no "Z"-suffix... Maybe it's even possible to get the timezone from the coordinates if none is provided by the timestamp.

I think the follwowing formats should be supported:

2007-04-05T14:30 (get timezone from coordinates, or just expect UTC) 2007-04-05T12:30-02:00 2007-04-05T14:30Z (the only format working for me)

Kind regards,

Kai

[tkrajina]

Hi Kai

Yes, I know the datetime parsing issues. I can add a list possible datetime formats and a 'strict' flag when parsing. If strict is False, only the strict GPX datetime format will be used (the one ending with Z) otherwise any of the list of available formats (you can then add yours if needed).

What do you think?

Regards, tk

[ghost]

GPX (1.1 at least) seems to specify dateTime as the format which can include the Z, but it doesn't seem to be required. I'd say that you should parse the dateTime with the Z, without the Z, and with the offset from UTC (+/- HH:MM) formats.

Anything other than those and I'd say you should pass in a callback function to handle any non-standard string to datetime conversions.

[KaiVolland]

I like both ideas.

My problem was, that i downloaded my gpx-files from my http://www.sports-tracker.com/ account and these tracks seems to have invalid timestamps: "2013-07-06T14:29:46.52" --> No Z or offset

This problem would be fixed by both of your solutions.

I like the solution with the whitelist of dateformats. That would bring up an easy way to expand the supported date formats, even if they are not valid... You should decide if you would like to support incorrect gpx-files or not.

bj1s idea is also satisfying and probably more straight forward.

[tkrajina]

bj1 & Kai, you're both! right.

I was speaking from memory but my memory is obviously faulty :) The 'T' must be there, Z isn't important. (BTW, gpxpy still don't work for gpx 1.1, it is on my "to do" list, but lack of free time... ):

The valid/strict timestamp formats are here: http://books.xmlschemata.org/relaxng/ch19-77049.html

Is anybody willing to make a list of strict formats function and (maybe) some common-but-unstrict, change parse_time(), add few unit tests and make a pull request? Otherwise, I'll do it, but probably not until the end of this month.

[tkrajina]

Here's my first try:

https://github.com/tkrajina/gpxpy/commit/680b513f21b750c3aa53786b44949f3a2a3a8059

Note that two use cases are not yet handled:

• negative years (i suppose this isn't a big problem, ancient Greeks and Romans had a rather poor GPS devices ;)
• UTC offsets (because %z for UTC offset don't work with strptime, and even if it worked it works for +0100 not +01:00)

If you want to try, use the timestamp-fix branch.

[ghost]

As you said in an earlier post, the 'T' must be in the timestamp, but it looks like the unit tests are testing version without the 'T' and are considering them to have passed.

It all depends on how strict you want to be with the standard.

[tkrajina]

Right, I decided to accept timestamps without the T for this first try. I'll probably keep it this way. Anyway, if users try to get the GPS back with get_xml() they will get the right timestamp format.