Make rotation start and rotation end take timezone into consideration

[teodosii]

What this PR does

• Fixes Rotation Start and Rotation End to take selected offset into consideration
• Fixed issue where week/month period was being restored when the offset was being changed (now it defaults to start of week, midnight, in selected timezone offset)

Related to #4428

[joeyorlando]

maybe worthwhile adding some unit tests for some of the time related utility functions, wdyt?

[brojd]

I can see the issue when you create Rotation that starts before / after DST change comparing to current time:

Screen.Recording.2024-06-07.at.07.01.41.mov

[brojd]

Another issue is that the day jumps to previous day if you select date that is before / after DST change:

Screen.Recording.2024-06-07.at.07.05.53.mov

Screen.Recording.2024-06-07.at.07.15.18.mov

[brojd]

I can see the following issues:

1. I create rotation that starts before DST change (27th March) in my system timezone at 2:00 having GMT+2 offset selected (so start time is 00:00 UTC), then created rotation has start time 01:00 UTC:

Screen.Recording.2024-06-11.at.10.22.15.mov

2. I create rotation that starts before DST change (27th March) in my system timezone having GMT+0 offset selected, then shifts are overlapping and "Limit each shift length" is enabled as soon as the rotation is created:

Screen.Recording.2024-06-11.at.10.26.47.mov

3. When I have GMT+0 offset selected, then I navigate in calendar to some date that is after the DST change in my system timezone, then the default value for start/end date of rotation is moved back to 23:00 of the previous day:

Screen.Recording.2024-06-11.at.10.33.18.mov

4. The rotation preview misses the last day of the week / month:

Screen.Recording.2024-06-11.at.01.43.40.mov

[teodosii]

Tests will be added separately as there's quite many cases to be handled and verified. before dst/during dst/after, switching from one period to another, changing the timezone etc