Creating endpoint for managing institution working times (BE)

[MariusJulius]

Wiki Design

Data stored in authorisation service

To-do:

• creating table for working times (?)
• creating endpoint for managing working times (get, update)
• check privileges - User has the privilege "Asutuse tööaegade muutmine" (edit_institution_worktime)

[DanBondarenko]

Note to all developers who are working with WORKING TIMES features:

• There’s complexity caused by the possibility that daylight saving time rules might differ between (a) the user who is saving and (b) the user who is viewing.
  • For example, if a user in China has saved 08:00–16:00, then when displaying to a user in Estonia, the displayed time should depend on whether it is summer or winter at the moment of viewing. If currently summer, Estonian equivalent is 03:00–11:00; if winter, it’s 02:00–10:00.
• To solve this issue, in addition to the chosen hours, we will also save the IANA Timezone Name (e.g. Asia/Shanghai) alongside the worktimes. Therefore, there will be a single root-level field worktime_timezone and, for each day of the week, two worktime fields (e.g. monday_worktime_start, monday_worktime_end).
  • On the front end:
  • When saving or changing working times, the current user’s IANA Timezone Name must be sent to the back end in addition to the selected time (e.g. const data = {worktime_timezone: "Asia/Shanghai", monday_worktime_start: "08:00", ... , sunday_worktime_end: null}).
  • Even if a single change is made, the full set of worktimes (Monday to Sunday) should always be sent to the back end. This avoids issues where some subset of worktime fields use a different timezone from the rest.
    • Logically, this means that if the user making the change is currently in a different timezone than the original worktime_timezone, then ALL of the previously evaluated worktime fields must be "translated" into the user’s timezone BEFORE sending the request to the back end.
  • Displaying the time can be tought of as two steps (examples with Luxon):
    • (1) Reading the time sent from BE. The hours must be interpreted WITH the wokrtime timezone (e.g. const mondayStart = DateTime.fromISO(data.monday_worktime_start, {zone: data.worktime_timezone});).
    • (2) Displaying the time to the viewing user. The hours must be "translated" to the viewing user’s timezone (e.g. const displayedStart = start.toLocal().toFormat('HH:mm');).
  • On the back end: *When business logic requires datetime calculations, then the time must be interpreted using the saved timezone (e.g. Date::parse($mondayWorktimeStart, tz: $worktimeTimezone)).