Improper time zone handling in schedules

[nilmerg]

Problem

The re-designed schedules introduced with #177 don't provide proper handling of different time zones.

As long as rotation entries created in the same time zone are visible and the viewer has said time zone configured, all is fine.

Problems occur once entries created in different time zones are mixed or if the viewer has a different one configured.

How to solve this

These data types are affected:

• Every MillisecondTimestamp: Those are already normalized to UTC upon persistence and back to the viewer's time zone upon retrieval
• rotation.first_handoff: This is only a date. A time zone can only be applied by combining it with the mode specific start time

The first goal should be to prevent edits in a different time zone.

TBD

To fix this, every date and time value must be normalized before being persisted in the database.

Note that it is important to perform the normalization as late as possible, to not to complicate the current implementation. It heavily relies on PHP's DateTime type, which is time zone aware, to perform calculations and comparisons. Deviating from the default time zone (the viewer's) too early will needlessly mess up many things.

Normalization must only be performed on values, which are final and are not referenced in further calculations or comparisons.

Upon retrieval from the database, previously normalized values must be transformed back to the current default time zone.

Considerations

Time period specific time zones
There's no real need for entry specific time zones. At the moment all entries of a time period, which is owned by a rotation, have the same time zone anyway. Transferring this to timeperiod.timezone would avoid potential future ambiguities.