According to "D00001309 FIT File Types Description Rev 2.1.pdf", page 9:
Unless otherwise specified, messages without timestamps are permitted in any order and messages with timestamps must occur in increasing order. Refer to individual file definitions for further details.
However FitCSVTool.jar will happily convert a CSV file to FIT with out of order timestamps:
Definition,0,event,timestamp,1,,,,,,,,,,,,,,,,,,,
Data,0,event,timestamp,842294601,s,,,,,,,,,,,,,,,,,,
Definition,0,record,timestamp,1,,position_lat,1,,position_long,1,,altitude,1,,speed,1,,,,,,,
Definition,0,record,timestamp,1,,position_lat,1,,position_long,1,,altitude,1,,speed,1,,enhanced_altitude,1,,enhanced_speed,1,
Data,0,record,timestamp,842294600,s,position_lat,-675816110,semicircles,position_long,-437206816,semicircles,altitude,4.8,m,speed,0.87,m/s,enhanced_altitude,4.800000000000011|4.800000000000011,m,enhanced_speed,0.87|0.87,m/s
Is this an error in the tool or in our understanding?
We don't have any problems encoding messages with out of order timestamps to a FIT file or parsing from a FIT file with out of order timestamps (Java libraries). Is the FIT File documentation suggesting that timestamp order may be expected by some FIT file readers/writers to be monotonically ordered, but not all readers/writers of FIT files may relax this requirement?
