CityStrides changing activity times by +5 hours

I don’t know why, and I don’t see a setting to change in either Runkeeper or in CityStrides. I have my pinned/default cities in Portugal, and my runs are in Portugal. When I signed up I was in Boston, so if anything I’d expect an error to be -5 hours, not +5 hours.

One of the only reasons this really bugs me is because sometimes it changes the date of an activity, for example, this run yesterday (7 Jul) at 8:03 PM ( becomes a CS activity at 1:03 AM the next day (8 Jul) (

There are a couple threads on this:

And Updates on May 7, 2021 (Release 93) made a change that should use your browser’s local time when displaying the date/time.

Ultimately, I have to figure out how to place the time zone on the activity itself. Most (all? it’s been a while since I’ve looked) services just send me a UTC timestamp and don’t even wish me luck.


Thanks! I didn’t realize this had been discussed before. I guess my experience fits in with that second post. But since you addressed this in Release 93, I don’t know why I’m still experiencing a 5 hour error since my activities and browser are occurring in the same time zone.

Hope it can be addressed in the future since the services themselves are able to take the time/date of the activity start from the gpx itself without issue.


I wonder why it’s displaying correctly for me… I definitely want to clean up this time zone issue, so I’ll be in touch after I have some time to work on it.

Perhaps you set it to YOUR browser time? I don’t think this is the problem, truly, but it gives me an excuse to post Only Who Can Prevent Forest Fires? (The Simpsons) - YouTube :joy::joy::joy:

Runkeeper sends over the date without any note of time zone as Wed, 7 Jul 2021 20:03:02, which I save as-is into the database.
Everything in CityStrides is “UTC at rest”, so that’s converted/stored as 2021-07-08 00:03:02+00.
When it’s displayed on the page, I’m using a bit of software that translates it from the stored UTC into the browser’s time zone.
I’m UTC-4 so that’s showing up in my browser as July 7 at 8:03pm
You’re UTC+1 so that’s showing up in your browser as July 8 at 1:03am


  • Runkeeper does not provide the activity’s time zone
  • My code seems to use its app-configured time zone, Eastern Time (US & Canada), when a zone is not provided


Before posting, I was looking around in user settings to see if I had set my time zone wrong, but there is nowhere to set it. Would it not be possible to give us the ability to set our own time zone in our CityStrides user settings alongside Name, Email, Default City, etc.?

Either that or some code to grab time zone from the city/region in which the nodes of the streets from the activity are located?

A user-level time zone setting wouldn’t completely solve the issue, because activities outside of your set time zone would continue to be wrong. A per-activity time zone is most correct.

I see two issues that I need to resolve:

  • Runkeeper should be providing time zone information; I need to figure this out myself as activities are created
  • I should be saving the time zone value on the activity & using it when displaying the date/time on the page

@kevincharlespels Does display the correct date/time for you now?

Further: does display as one hour off (11am instead of 10am)?

1 Like

Yes, it now does! Thank you!

Thanks for checking - I updated my post before realizing you responded.

Does display as one hour off (11am instead of 10am)?

Yes, that activity was at 10:03 AM on my time so it is 1 hour later

OK, thanks…

Outside of that activity, do you mind spot-checking some (maybe 4?) to see if they now display the correct date/time?
I think, ideally, you’d pick a couple activities that occurred during DST and a couple that did not - to be sure that I’m adjusting those properly.

hhmmm… @kevincharlespels also let me know if new activities end up with wrong date/time :thinking: I’m seeing some odd stuff
thanks for working with me on this & sorry that you have to it’s happening

Well, now that you mention it, this activity I just synced is also off by an hour (started at 9:31 AM local time, says 10:31 AM on CS)

Ditto for this one yesterday (started 6:04 PM, says 7:04 PM)

But this one is correct all the way thru
This one too (checked because it was after 8PM local time and with the +5 hours previously pushed it to the next day)

Going further back to pre-DST, things getting a bit more screwed up again. This activity was at 11:56 AM local time, CS says 7:56 AM (-4)
Same here (actual 10:37 AM, CS 5:37 AM (-5))

So now some of my times are all over the place :upside_down_face:

Hope this helps you figure out what’s going on. I appreciate you always working to make CityStrides better and being so responsive with the community!

Ah, ok - sorry for my lack of detail!

I was only working on Runkeeper activities, so all your Garmin activities were still wrong.
I’ve just adjusted all your Garmin activities, so those should all display correctly now.

So… now…

  • Runkeeper activities from before July 13, 2021 should be correct
  • All Garmin activities should be correct
  • Runkeeper activities from July 13 → (whenever I fix this thing) might be somehow wrong (it sounds like off by an hour too late)


This off-by-one-hour issue seems to be my server/platform code incorrectly translating the stored date/time into the activity’s time zone’s date/time. So, I’d expect that all your DST activities from Runkeeper are off by one.

Using activity as an example…

  • The date time in the database is 2021-07-15 08:31:17 UTC
  • When I convert it to the time zone of the activity, it’s Thu, 15 Jul 2021 10:31:17.000000000 CEST +02:00 (even though you’re +1, not +2)

This looks caused by your time zone being Europe/Lisbon, and I’m using UTC offset to determine the translation (3600 in your case), but when I ask for that date/time in “time zone” 3600, it spits back CEST which is -2.

I think I can solve this by avoiding the helpers my code platform offers & do the calculations off UTC myself.
In the meantime, I’m resetting your older Runkeeper activities so that I can take a fresh look…

Cheers, this seems like a giant pain in the ass made even more complicated by me switching my linked service a few times. Hopefully it pays off in being correct for others!