Displayed time incorrect in logged out state

[MrKrisKrisu]

Describe the bug A user reported that since the timezone update, there is a discrepancy in the displayed train schedule on their profile. When viewing the profile without logging in, a train scheduled for 19:10 is incorrectly shown as 17:10. However, upon logging in, the correct time of 19:10 is displayed for the same train journey.

To Reproduce Steps to reproduce the behavior:

1. Visit the user's profile in an unlogged state.
2. Locate the train departure time for a specific train, e.g., 19:10.
3. Observe that the displayed time is incorrect, showing 17:10 instead.

Expected behavior The user expects that the displayed train schedule in both logged-in and unlogged states should consistently show the correct departure time of 19:10.

Screenshots

//

Desktop (please complete the following information):

//

Smartphone (please complete the following information):

//

Additional context Internal Ticket #220064

[TobiTobsen1410]

Hi guys, Since the timezone feature came up, trains show a different time when I’m logged out (minus 2 hours) than when I’m logged in into my profile. I attached two pictures to this message to show you the problem. Cheers, Tobi

[HerrLevin]

Temporary fix w/ #1963 - This will only be fixed, once we can handle all date/time formatting in the frontend. A better backend time formatting is just not worth it in this case.

[MrKrisKrisu]

Temporary fix w/ #1963 - This will only be fixed, once we can handle all date/time formatting in the frontend. A better backend time formatting is just not worth it in this case.

Is it possible to detect the timezone from the client?

[pascalwittler]

@MrKrisKrisu

Is it possible to detect the timezone from the client?

It is possible to detect the client's timezone using Javascript:

(new Date()).getTimezoneOffset(); // -120 for Central European Summer Time

As far as I know, there is no reliable way to determine the timezone of a client system from the server side using PHP as it is neither provided in the HTTP request nor in the $_SESSION superglobal by default.

A possible but unsatisfactory workaround would be to set a cookie with the result of the above javascript code and read its value via PHP (which of course would only work from the second page load on and would probably make consent necessary).

Doing the magic of displaying date and time in the frontend as mentioned by @HerrLevin seems to be the least painful solution.