search

tkrajina / gpxpy

gpx-py is a python GPX parser. GPX (GPS eXchange Format) is an XML based file format for GPS tracks.
Apache License 2.0
987 stars 223 forks source link

Custom date formats #13

Closed neithere closed 10 years ago

neithere commented 11 years ago

Thanks for the excellent library with such a clean API.

Now to the problem. My selection of .gpx files was generated by two N9 applications: SportsTracker and GPSLogMee. Both save the timestamps in formats that don't match gpxpy.gpx.DATE_FORMAT. SportsTracker seems to follow ISO 8601 (which is implied by GPX) while GPSLogMee sticks to RFC 822 for some reason. However ugly it is, monkey-patching the format string mostly helps... but SportsTracker sometimes omits microseconds (which defeats the possibility to correctly parse the whole file generated by ST). And, indeed, even ISO 8601 implies a certain degree of variability, not to mention the deviations from canonical GPX.

So, the date/time format depends on the data source and there can be more than one valid date/time format per data source.

Possible solutions:

  1. ease the pain of monkey-patching by converting gpxpy.gpx.DATE_FORMAT into a list of strings (and possibly populate it with multiple common formats);
  2. allow passing a list of possible date/time formats to the parser.

What do you think?

tkrajina commented 11 years ago

Hi Andy,

I vote for a list of valid timestamp format strings + a list of common (but GPX-invalid) format strings.

And then a strict flag for the parser. If strict is True -- only the valid timestamps formats used, otherwise all timestamp formats will be tried when parsing.

The "strict" flag may be used in the future for other similar features (for example emails, icons, ...).

neithere commented 10 years ago

I don't think an issue should be closed unless the problem is resolved.

The "strict" flag is a good idea but I would probably never use it; someone might, so I don't see any reason why I should discuss it here. It does not solve this issue.

Then, the list of common format strings is something much closer to solving the problem described in the original message, but who is going to maintain that list, what criteria are going to be used to accept/decline adding, etc.? Maybe everything that dateutil understands should go there. Or the list should be populated step by step on request.

Anyway, what directly solves the issue and requires minimum amount of changed/added code is converting the string to a list with one string. This would be enough to monkey-patch that de-facto setting and then a less hacky way may gradually emerge.

tkrajina commented 10 years ago

I closed it because there was no response (and since at the moment you are the only one who needs this feature, it seemede to me that there was no need for it). But, OK, it is reopened now.

Anyway,

Or the list should be populated step by step on request.

I think this is the right way. Because the GPX standard is pretty strict about it and I don't believe the list will be too long. So I'm willing to add new formats by request.