Wrong date in recorded GPX track

[scaidermern]

Description

Yesterday I've recorded two tracks using OsmAnd 4.6.6. Somehow, OsmAnd managed to create them with a wrong date in the timestamps.

OsmAnd recorded
2004-04-15_18-32_Thu / 2004-04-15T16:59:55Z
while the correct time stamp would have been
2023-11-30_18-32_Thu / 2023-11-30T16:59:55Z

The date is wrong, the time is correct. The day of the week is also correct but funnily, both 2023-11-30 and 2004-04-15 are Thursdays.

Not only the name of the track has the wrong date, also every track point has wrong timestamps. Overall, the date and times are consistent, i.e. the date stays the same wrong value and the seconds and minutes of the time increase as expected.

I've attached both tracks but removed most of the track points for privacy reasons:

• 2004-04-15_18-32_Thu.txt
• 2004-04-15_19-12_Thu.txt

Date and time on my phone have been correct. I've never had this behavior before. I'll try to keep an eye on future track recordings.

This reminds me a little about #13945.

Steps to reproduce

No idea.

Actual result

Date and time are wrong.

Expected result

Date and time are correct.

Your Environment (required)

OsmAnd Version: 4.6.6
Android/iOS version: Android 10
Device model: Samsung S9

[scaidermern]

Easy to reproduce. Happens again with every new track recording. Recordings from today use 2004-04-16.

[alex-osm]

Regression after #18426

[vshcherb]

So we either have this issue or this #18170, interesting... Actually from sanity of code this is wrong issue cause it has wrong GPS chipset time and we need to understand how to work around it

[vshcherb]

But better to understand which GPS devices are affected cause hotfix to check years difference might be not necessary good

[mbartlett21]

It is precisely 7168 days (1024 weeks) out of sync. See https://en.wikipedia.org/wiki/GPS_week_number_rollover and https://en.wikipedia.org/wiki/GPS_signals#Time.

[vshcherb]

To do: if difference >= 4 weeks use System.currentTimeMillis