Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync Timezone issue #631

Open
bcumber opened this issue Feb 8, 2024 · 2 comments
Open

Sync Timezone issue #631

bcumber opened this issue Feb 8, 2024 · 2 comments
Labels

Comments

@bcumber
Copy link

bcumber commented Feb 8, 2024

Describe the bug
The home screen of the windows desktop application doesn't seem to use the correct timezone when querying for "today's" workouts.

My first workout is usually around 6:00 am MT. After that 45 minute - 1.5 hour workout I usually do a stretch or something starting sometime after 7:00 am. When I open the application to sync my workouts for the day it is usually sometime around 7:30 am MT. The home screen will only show workouts that I started after 7:00 am MT. It does not show the 6:00ish am workout.

Navigating to the Sync page shows all of the expected workouts. The fun part is that the date/times are correct for all of those workouts. It correctly shows the 6:00 am class.
image
image

To Reproduce
Steps to reproduce the behavior:

  1. Workout at 6 am
  2. Workout again at 7 am
  3. Open the windows desktop application via the ClientUI.exe
  4. Take note that the 6 am class does not appear above the "Sync todays workouts" button.
  5. Navigate to the Sync page.
  6. Take note that all expected workouts are there and show the correct date/time.

Expected behavior
I would expect all workouts that have been started since midnight of my timezone would show in the application.

Logs
Don't think the logs are going to show anything useful. Let me know if you still want me to include them.

Installation (please complete the following information):

  • OS: windows
  • Method: exe
  • Version: 4.10

Additional context
I know I've seen some notes in the docs and some issues on github that mention a Timezone environment variable, so please forgive me if setting that is all I need to do to fix the issue. If that is the case though, I would imagine that getting the current timezone of the system that is running the application would be possible. I'd be happy to look into implementing that improvement if that is what needs to happen. Likewise, if it is a bug, let me know if you need some help looking into it. If you point me in the right direction, I could see if I can find the issue. Thanks! I love the application.

@bcumber bcumber added the bug label Feb 8, 2024
@bcumber
Copy link
Author

bcumber commented Feb 28, 2024

I looked into this a bit more. It seems like the workouts from the peloton API are not being stored in UTC, but rather in the timezone that the class was taken in. In my case, working out at 6 am MST results in a UTC time of 1 pm. The query that is used to request the data is getting midnight of the current time zone and converting that to UTC and using that value as the start time. In my case that is a UTC value of 7 am. The end time for the query is DateTime.UTCNow, which makes sense in this case (but there may be a separate bug with that) and would result in a UTC value of sometime after 2pm UTC. All of that logic is sound and should result in all workouts between 7am UTC and ~2pm UTC. Unfortunately, I only see workouts after 7am MST as a result of that query. That's what is making me think that the workouts are actually stored in the local time that the class was taken. If I have time this week, I'll see if I can put a PR together for a potential fix.

@manc74
Copy link

manc74 commented Mar 31, 2024

I see the same issue here in the UK each time we switch to daylight savings (BST).

I reported the bug this time last year here:

#460 but can confirm the bug still exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants