Skip to content

Conversation

@jrauh01
Copy link
Contributor

@jrauh01 jrauh01 commented Oct 17, 2025

This PR introduces timezone support for schedules. It relies on the schedule.timezone column in the database added in Icinga/icinga-notifications#344.

For the following explanation, it is important to understand the difference between schedule and display timezone.

  • schedule timezone: the timezone the schedule is created for and stored in the database.
  • display timezone: the timezone the user want to display the schedule in.

Schedule List

The timeline part has been removed completely, so that we don't have to create a header for each schedule which wouldn't be very well readable.

Schedule Creation

The form to create a new schedule now has a suggestion input to choose the timezone the schedule will be created for. Once created, the timezone cannot be changed via the web UI, because the suggestion input won't be displayed for the editAction(). This is ensured with a bool $showTimezoneSuggestionInput in the ScheduleForm which defaults to false. The default of the suggestion input is the timezone configured in the the user preferences. The value of the suggestion input will be stored in the schedule.timezone column.

ScheduleTimezoneStorage

The ScheduleTimezoneStorage is a util storage class which stores the schedule timezone globally. The schedule timezone is set in the ScheduleController::indexAction().

Schedule Detail View

The timeline start is in the display timezone and is passed to the ScheduleDatail in the ScheduleController::indexAction(). The rotation.actual_handoff and timeperiod_entry.start_time are stored as unix timestamps, so the entries are displayed correctly in the timeline grid. Additionally all date formatters are constructed with the display timezone, so all titles are displayed correctly for the user's choice.

The user changes the display timezone via a dropdown control called TimezonePicker. This may be change in the future.

Rotation Config Form

All configurations in the form are done in the schedule timezone, no matter what display timezone is chosen. The RotationConfigForm is constructed with both the display and schedule timezone. If the display timezone differs following will happen:

  • A warning is displayed to make the user aware that they configure the rotation in the schedule timezone.
  • The first handoff hint is complemented by an additional hint that shows the first handoff in the display timezone

The dropdowns to select times did show 'Next Day' hints earlier. This logic has been replaced by an own option group for next day elements.

Requires Icinga/icinga-notifications#344
Requires Icinga/ipl-scheduler#55
Fixes #273

@jrauh01 jrauh01 self-assigned this Oct 17, 2025
@cla-bot cla-bot bot added the cla/signed CLA is signed by all contributors of a PR label Oct 17, 2025
@jrauh01 jrauh01 force-pushed the fix/schedule-timezone-handling branch from efafe1d to 1b6de94 Compare October 27, 2025 11:34
@jrauh01 jrauh01 force-pushed the fix/round-times-to-1130-pm branch from 229f6a8 to edfee49 Compare October 27, 2025 12:36
Base automatically changed from fix/round-times-to-1130-pm to main October 27, 2025 13:52
@jrauh01 jrauh01 force-pushed the fix/schedule-timezone-handling branch 4 times, most recently from 18670a3 to bb75f8d Compare October 28, 2025 14:24
@jrauh01 jrauh01 requested a review from nilmerg October 28, 2025 14:26
@jrauh01 jrauh01 force-pushed the fix/schedule-timezone-handling branch 2 times, most recently from 8e83df5 to eaecd7b Compare October 30, 2025 14:24
@jrauh01 jrauh01 requested a review from nilmerg October 30, 2025 14:40
@sukhwinder33445
Copy link
Contributor

Some timezones from DateTimeZone::listIdentifiers() are not supported by IntlDateFormatter.
The method IntlTimeZone::createEnumeration() provides valid, supported time zones. Please use this instead.

Please make sure the daemon also supports these time zones, or filter out unsupported ones to avoid runtime errors.

@jrauh01 jrauh01 force-pushed the fix/schedule-timezone-handling branch 4 times, most recently from ffe5cb7 to b8a9709 Compare November 6, 2025 10:07
@jrauh01 jrauh01 requested a review from nilmerg November 6, 2025 10:10
@jrauh01 jrauh01 force-pushed the fix/schedule-timezone-handling branch 4 times, most recently from aa87261 to 5ea4e7b Compare November 7, 2025 14:39
@jrauh01 jrauh01 requested a review from nilmerg November 7, 2025 14:42
@jrauh01 jrauh01 force-pushed the fix/schedule-timezone-handling branch from 5ea4e7b to a7b76af Compare November 10, 2025 11:46
Makes use of `ScheduleDateTimeFactory`.
A Widget that represents a warning if the display timezone differs
from the schedule timezone. It's used for the forms to add and edit
rotations.
...if the display timezone differs from the schedule timezone.
Use the schedule timezone to configure rotations. All times entered
are handled in the schedule timezone.
This is because we want to remove the parentheses for future
changes where those should be used to display a time in another
timezone.
In the dropdown menu in the rotation config form show times in the
display timezone in parentheses next to the normal time (schedule
timezone).
... if the display timezone differs.
... to prevent the schedule view mode switcher resetting the
timezone picker.
... by `ScheduleTimezoneStorage`. This just stores the display
and schedule timezone, instead of creating `DateTime` objects.
... instead using schedule timezone.
Some timezones from `DateTimeZone::listIdentifiers()` are not
compatible with the `IntlDateFormatter`. So now we get the timezones
from `IntlTimeZone::createEnumeration()`. This provides timezones of
**type 2 and 3**. Type 2 timezones cause problems, so we want to filter
them out. To make sure we only get timezones from **type 3**, we check
if they have a location. (Only type 3 timezones have a location).
Show the first handoff in the display timezone if it differs to the
schedule timezone.
In the dropdown menu in the rotation config form from now on don't
show times in the display timezone in parentheses next to the normal
time (schedule timezone).
Instead of using an url param that has to be preserved by every
link, form action or redirect, we now use the 'notifications'
session namespace to store the display timezone for the current
user. The start day for the timeline now comes from the
controller, no longer from the schedule detail controls.
If the entries shift to another weekday in the display timezone the
flyouts have to point this out. For that we shift the days array
for **partial** mode rotations or the start and end days for
**multi** mode rotations.
The schedule timezone is set on the entry and then passed to
`FlyoutEntry::generateAndSetRotationInfo()` as argument. The
display timezone is set via the constructor.
Because it's nowhere used anymore.
Instead of handling the session in `TimezonePicker`.
@jrauh01 jrauh01 force-pushed the fix/schedule-timezone-handling branch from b9b55fe to d988517 Compare November 10, 2025 14:46
@jrauh01 jrauh01 requested a review from nilmerg November 10, 2025 14:49
Copy link
Member

@nilmerg nilmerg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 🎉

@nilmerg nilmerg merged commit 34beeb2 into main Nov 10, 2025
10 checks passed
@nilmerg nilmerg deleted the fix/schedule-timezone-handling branch November 10, 2025 15:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla/signed CLA is signed by all contributors of a PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Improper time zone handling in schedules

4 participants