-
-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dates with fractional seconds cannot be parsed on Linux #100
Comments
Apologies @georgbachmann, I didn't see this until today. The thing with DateFormatters in my opinion are that they are pretty slow, at least in the context where you need to parse like hundreds or thousands of dates, so I'm not sure if a fallback would be a good idea. I think having an option would be better because of that. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a service where I would like to use CoreGPX and noticed, that there is a difference in date-parsing between local development on my Mac and running it on linux. I have a GPX file with a date like so:
<time>2023-04-25T07:58:06.001Z</time>
(seems like Polar does that) and those cannot be parsed. When I remove the fractional seconds from that date string (like so:<time>2023-04-25T07:58:06Z</time>
everything works fine.So I did some digging and found that CoreGPX is using
That
ISO8601DateFormatter
wold have the option todateFormatter.formatOptions.insert(.withFractionalSeconds)
and then it would parse the date.... BUT :) it will not parse dates any more, that don't have fractional seconds.I don't know that much about dateformatters and if there is an option to tell it to try both... but maybe we could have two formatters? The one without and then fallback to the one with fractional seconds? I wasn't too sure which way to go, so I thought raising an issue before doing a PR to discuss it.
The text was updated successfully, but these errors were encountered: