GPSrChive Discussion Forum

Like I said, BaseCamp for Windows does not put a timestamp on the first track point, but the Mac version does.

aleph wrote: Tue Apr 08, 2025 7:14 pm Did you import it to a device?
Just curious to know if the info (first tab when opening the track) is also strange

Never paid any attention to it, but the same happens on my Oregon 700... It shows the value of 883854:3
Can't check it in Explore because it doesn't support synchronising with the Oregon.
After removing the timestamp it shows a value of 0:00 (as expected), and with a manually added, different timestamp on the last trackpoint it shows the duration of the track.

@przekatny
Sorry - I don’t see what you mean?
Already mentioned: Mac sets a time (as I mentioned and Javawa)

Still don’t understand why the “time”’has that value in the device


Has anyone tried to reproduce (with a Mac generated Track)

Thanks

The device tries to calculate the duration of the track. It substracts the timestamp of the first point from the timestamp of the last point. When there are no timestamps the default value of "0" is used. It goes wrong when there is a timestamp on the first point but not on the last point. The result is negative, but when the variable that is used to store it cannot be negative, it may result in a very large positive value.

You don't need a Mac to test it, just open the file in a text editor and put a timestamp in the first trackpoint.

thank you for the help!

aleph wrote: Wed Apr 09, 2025 5:55 pm Still don’t understand why the “time”’has that value in the device

I am not surprised by the travel time provided, but by the fact that it is provided at all.

A manually created path is a universal form, it is not assigned to any activity, determining the travel time basically does not make sense, a designated path can be used by a pedestrian, cyclist or in motor activity.

I do not see the point of determining the travel time for a path with an unspecified activity.