viking-gps
GPX-Export time with dummy digits
when I use the GPX-Export function after transforming way-points to a track: <File> -> <Export All> -> GPX... the time format has three additional "dummy digits (000 or 999)" before "Z". With that other GPS-Applications like GPSprune or QMapShack do not import the time value, because they expects a maximum of three digits between "." and "Z".
I respectfully contend that the other applications are incorrect.
The GPX 1.0 specification - https://www.topografix.com/gpx_manual.asp#time - says that time is ISO 8601. NB this doesn't specify any particular version of ISO 8601. From Wikipedia - https://en.wikipedia.org/wiki/ISO_8601 - it says:
There is no limit on the number of decimal places for the decimal fraction.
For GPX 1.1 specification - https://www.topografix.com/GPX/1/1/ - time definition is subtly different (but ultimately practically the same). Now it is xsd:dateTime, which as far as I can tell is https://www.w3.org/TR/NOTE-datetime which is "a profile of ISO 8601".
This profile does not specify how many digits may be used to represent the decimal fraction of a second. An adopting standard that permits fractions of a second must specify both the minimum number of digits (a number greater than or equal to one) and the maximum number of digits (the maximum may be stated to be "unlimited").
Hence I believe GPSprune and QMapShack should except the values produced by Viking, and in general follow the https://en.wikipedia.org/wiki/Robustness_principle
Further note that internally Viking uses the function g_time_val_to_iso8601(). This is used for all timestamps (whether the track has been created by converting waypoints to a track or any other method). Viking could process this output to remove unnecessary ending '0's, but that would not resolve cases ending with '999'.
I could add a GPX Export preference to specify a limit of number of digits for the decimal fraction on timestamps, but that may be a bit of an overhead and/or error prone itself as one might try to take the answer g_time_val_to_iso8601() and have to extract the decimal fraction and round it to the specified limit (rather than simply truncating the value).
Thank You for the detailed explanation. So it seems that some application developers do not use the exact ISO 8601 specification? For me I hope that the Windows version of Viking will work in the near future. It will take me a while, to switch to a linux desktop with my applications.