When clicking on timeline - shows a previous day

[grillop]

Describe the bug
Not sure if it is a bug or feature. However, when I click on the timeline in the upper left corner, I am always presented with the same day a month ago. I created a separate account am loading the gpx points via a file upload into the api. I do not know if that has anything to do with it.

To Reproduce
Not sure anybody else can reproduce this - as I do not know what I did to get to this point.
Hoping that this might be a setting I'm missing or something that might occur to the developers

Expected behavior
Display the current day - as my normal account that i use does

Screenshots
you can see the february date - and there is no lock or anything on it

Desktop (please complete the following information):

• OS: I switched to development branch docker image. Running on unix/debian 12
• Browser happens on Firefox, Brave, and Edge

Additional context
Add any other context about the problem here.
well, it seems to happen within my account where gpx files are uploaded in bulk. I have also noticed that at times, there is no trip data on some days in the account that uses only bulk update. i have a parallel account that runs "normally" where my phone pushes the captured points one at a time with a custom url. That account shows normally, and on those days where the bulk account shows no trip data - the non bulk account shows a trip. the track matches exactly, but no trip

i dont' know if this is related, but here is a exception trace that continually takes place - seemingly after an upload. might not be related - but also worth noting.

2026-03-12T15:28:16.242Z INFO 1 --- [io-8080-exec-82] c.d.reitti.service.importer.GpxImporter : Successfully imported and queued 690 location points from GPX file for user xxxxxx
2026-03-12T15:28:16.355Z ERROR 1 --- [pool-5-thread-1] c.d.r.s.p.LocationDataIngestPipeline : Error during processing:
java.lang.IndexOutOfBoundsException: Index 6448 out of bounds for length 6448
at java.base/jdk.internal.util.Preconditions.outOfBounds(Unknown Source) ~[na:na]
at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Unknown Source) ~[na:na]
at java.base/jdk.internal.util.Preconditions.checkIndex(Unknown Source) ~[na:na]
at java.base/java.util.Objects.checkIndex(Unknown Source) ~[na:na]
at java.base/java.util.ArrayList.get(Unknown Source) ~[na:na]
at com.dedicatedcode.reitti.service.processing.GeoPointAnomalyFilter.filterBySpeed(GeoPointAnomalyFilter.java:84) ~[!/:0.0.1-SNAPSHOT]
at com.dedicatedcode.reitti.service.processing.GeoPointAnomalyFilter.detectAnomalies(GeoPointAnomalyFilter.java:37) ~[!/:0.0.1-SNAPSHOT]
at com.dedicatedcode.reitti.service.processing.AnomalyProcessingService.processAndMarkAnomalies(AnomalyProcessingService.java:35) ~[!/:0.0.1-SNAPSHOT]
at com.dedicatedcode.reitti.service.processing.LocationDataIngestPipeline.processLocationData(LocationDataIngestPipeline.java:73) ~[!/:0.0.1-SNAPSHOT]
at com.dedicatedcode.reitti.service.DefaultImportProcessor.lambda$processBatch$0(DefaultImportProcessor.java:51) ~[!/:0.0.1-SNAPSHOT]
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:na]
at java.base/java.util.concurrent.FutureTask.run(Unknown Source) ~[na:na]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[na:na]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[na:na]
at java.base/java.lang.Thread.run(Unknown Source) ~[na:na]

[grillop]

So, I took it upon myself to look into the DB. It would appear that the user_settings for that particular user had that old date in the latest_data column. Never seemed to change - don't know how it got there. I modified it - set it to null. and now things are working okay.
So, more info - choose to close this or not. There is possibly still an issue with trips not being created - but, I can continue to monitor that and re-post if that makes sense. Unless the developers somehow view that exception as relating to the issue

[dgraf-gh]

Thank you for the report. Lets keep that open and I will have a look at the error. I remember soemthing similar in the past.

[dgraf-gh]

I checked the code, and there is a bug in the current release which prevents calculating the speed in certain circumstances. I remembered correctly that I have seen this. But the fix is only in the next branch for the 4.0 release.

I am uncertain if I want to pull it down and issue a hotfix for this since there is a whole lot of additional stuff done.