The getDate converter from timestamps to luxon.DateTime objects has a hardcoded "utc+2" time zone offset. It does not actually know the time zone, and when western Europe goes back into UTC+1 when DST ends, there will be a mismatch.
Steps to Reproduce
Wait until DST ends
Authenticate and enter the Dashboard
Observe incorrect date on time axis of bar chart
Desired Behaviour
The first step is a consistent operation in Zulu time: no time zone offset, no DST.
Currently time ranges returned by the backend are converted from ISO time with tz offset by:
new Date(endpointTW.start).getTime();
and they are formatted back into textual representation by various functions including:
The correct conversion should also interpret date range picker input as UTC Zulu time.
The second step tries to convert a date in the user context including the user's time zone. The timestamp for the New Year will be the timestamp of the New Year on the user's local timezone by default, but users will have the possibility to work in any other time zone. The conversion will use the adequate time zone offset including when DST ends and the hour from 2AM to 3AM is repeated. The first repetition should be 02:30+02:00 and the second should be 02:30+01:00 (the time zone offset changes).
Admins will have the possibility to set a default time zone which overwrites the user choice when the session opens (only, it shall not prohibit changing the time zone temporarily).
https://github.com/Natixar/natixar-frontend/blob/00381294e086ae5f64368c64b67133a09d24a678/src/data/domain/transformers/TimeTransformers.ts#L20
Problem
The
getDate
converter from timestamps to luxon.DateTime objects has a hardcoded "utc+2" time zone offset. It does not actually know the time zone, and when western Europe goes back into UTC+1 when DST ends, there will be a mismatch.Steps to Reproduce
Desired Behaviour
The first step is a consistent operation in Zulu time: no time zone offset, no DST. Currently time ranges returned by the backend are converted from ISO time with tz offset by:
and they are formatted back into textual representation by various functions including:
The correct conversion should also interpret date range picker input as UTC Zulu time.
The second step tries to convert a date in the user context including the user's time zone. The timestamp for the New Year will be the timestamp of the New Year on the user's local timezone by default, but users will have the possibility to work in any other time zone. The conversion will use the adequate time zone offset including when DST ends and the hour from 2AM to 3AM is repeated. The first repetition should be 02:30+02:00 and the second should be 02:30+01:00 (the time zone offset changes).
Admins will have the possibility to set a default time zone which overwrites the user choice when the session opens (only, it shall not prohibit changing the time zone temporarily).