Work with timezones

[Gerben321]

This is one that I have been thinking of for a little while, and I was wondering if it's worth it. But then it became clear. Bike Care needs to work with timezones.

The point is, that Strava activities are reported in UTC timezone. This means that 12:00 UTC time is for example 13:00 in Amsterdam. If you configure your component periods, I would for example add '01-01-2024 13:00' as start date. Because I installed the component at 13:00 local time. This is then saved as the same input in the database. But the data in the database is considered to be UTC.

This means that when Bike Care does the distance calculations for a component or a bike, it will use the UTC dates from activities and tries to find corresponding component periods, which it also thinks are UTC.

If a component is installed on 01-01-2024 at 13:00 local (Amsterdam) time, and you ride at that day at 13:10 (which is 12:10 UTC time) for let's say 10 minutes, it will not match the component usage period with that activity. In UTC terms this means the ride was between 12:10 and 12:20. But the component period is saved as 13:00 (local time) in the database. While if this was saved as 12:00 (UTC) it would match.

It's a bit late and my mind isn't clear anymore, so can you guys think this over and confirm it, to be sure my logic isn't flawed? @Konstantin-Levin & @OleksiyRudenko ?

I've now got the most of the heavy work done. The only drawback is that if you're not using the UTC timezone (London is on it), your component periods and things like that will move back or forth for an hour or two (depending on your timezone obviously).

[Gerben321]

For now I've added another user setting to set this up: I'll see if I can get the list a bit smaller to only the actually timezones or something. But this is something you set up once, so shouldn't be a huge issue otherwise.

All inputs from forms will be your local times. So if you have done service at 13:00 you enter that. In the background this value will be converted into UTC. And every time it's displayed somewhere it's returned back into your timezone.

[OleksiyRudenko]

Makes sense. Also London is UTC in the winter period only.

Does Strava API allow you to get location from the user profile? Maybe it even allows you to get time offset. It would be a better UX if BikeCare relied on Strava data rather than on the user input.

[Gerben321]

Ah yes the dst. I believe I get a start date on an activity, and a local start date. The local date includes the timezone you set in strava I believe.

Not sure if the profile itself also contains that. I can't find it in the strava profile settings. So strava just uses the timezone of where you do an activity.

Anyway, my solution should also work with dst. So when you enter a service log or a component period, enter it in your countries timezone. The only situation this will not work if you're in another country in holiday and you enter that timezone. But maybe that's just an edge case. I can't imagine that would cause a problem, for myself at least. Or you just set the timezone to the one you're in currently to solve that. But that's something you have to keep in mind when you're abroad.

[Gerben321]

Made the dropdown a bit friendlier to use. I've grouped the timezones in regions. It's also an autocomplete field which means you can search for a big nearby city.

[Gerben321]

This is now deployed. Please set your timezone to the correct one. Your mileage will not be affected by this because the data in the database is not altered. However, the times may appear differently when viewing them. This is because I convert them to your timezone now. If your mileage per bike and component is now correct you shouldn't have to change it, unless you want to correct it yourself.