Date not saved correctly

[John-H-Smith]

when tracking track time for a project, the saved date is always set to the day before (yesterday by default) or the day before the selected date.

[faburem]

Can you please provide a bit more context? Screenshot, Timezone information. I know this issue is has been reported in the past and we might have introduced a regression with the latest upgrade to Meteor.js version 3.0 but I still need that information for troubleshooting - thanks for your understanding!

[lylebrown]

I can add more context as I'm seeing this as well. If I try to track time from a calendar view, if I click on a day or drag a project to a day, the dialog box that appears always sets it to the previous day.

I actually don't see where to add a time zone in the settings? But my time zone is United States/Phoenix.

I'm seeing this issue regardless of if I set my start day of the week to 0 or 1, and changing the time unit from the profile drop down does not make a difference either.

I am running the container in podman (which should be close enough to docker to not make a difference).

I see the following error in the log (but no other errors) -

[ERROR: Exception in setTimeout callback: @ Fri Dec 13 2024 10:32:28 GMT-0700 (Mountain Standard Time)] { 

  "browserInfo": { 

    "browser": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0", 

    "userId": "{REDACTED}", 

    "url": "https://{REDACTED}/tracktime?date=2024-11-30&view=M", 

    "resolution": "3440x1440" 

  }, 

  "stack": {} 

} 

[faburem]

Hello and thanks for providing more information on this issue!
Podman should definitely work the same way as docker. I also think the error stack is unrelated but I will investigate it further regardless.
The reason why you don't see a timezone setting is that we are trying to autodetect it, convert it to UTC on the server and then convert it back to your timezone when data is displayed. I am starting to think that we are over complicating things since this has caused multiple issues in the past already. Having a manual setting for the timezone might mitigate this issue since we could use it on both server and client. I will work on a proof of concept an report back in this issue.

[lylebrown]

As a potential solution, one thing I've done with other mongo containers is pass the following volume:

- "/usr/share/zoneinfo/America/Phoenix:/etc/timezone:ro"

This allows for the timezone to passed from the host to the container. I'm not sure if this would be any easier than just configuring it to be a manual option in the settings, though.