Rotations: Deprecated timezone leading to text rendering issues

[arurao]

Describe the Bug:
Text rendering issues have been observed on some browsers (e.g. Chrome) for deprecated timezones.
This is happening because of some timezones (like 'US/Central') being deprecated and hence, not being supported by all browsers, but the backend database (Postgres) still considers them as valid.

Steps to Reproduce:

1. Go to 'Rotations'
2. Click on any one rotation to go to its details page.
3. Scroll down to the description text for the rotation, most often starts with 'Hands off....'
4. See error like 'Invalid DateTime US/Central...'

Expected Behavior:
A proper text description for the rotation handoff date and time is expected.

Observed Behavior:
A rendering error is observed in that text with 'null' handoff day of the week and/or 'Invalid DateTime' for timestamp.

Screenshots/Stack Traces:

Application Version:
v0.22.0

Desktop:

• OS: MacOS
• Browser: Chrome

Additional Context:
This issue is only limited to the UI. Scheduling still works as intended.

A possible workaround for this issue is to replace the deprecated timezone with it's equivalent non-deprecated one.
For example: Replace US/Central with America/Chicago

For more information on which timezones are deprecated and their equivalent zones, please refer to https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.

[mastercactapus]

We could probably look at embedding tzdata in the backend and using that. Postgres is only used because we can list them easily. However, all TZ-type calculations happen in GoAlert itself, which then uses whatever is available on the system.

In the official container, which is based on Alpine, the package uses the IANA db:
https://www.iana.org/time-zones

But if we embed it, we can guarantee GoAlert will have the same TZ data for a particular version/binary on all systems & environments. It also has a list of linked non-canonical names we can use.

We might still have issues on windows systems unless Chrome & friends have their own TZ data.
https://golang.org/src/time/zoneinfo_windows.go#L20

---

If we go forward with that, then next steps would be:

• Work out a way to embed TZ data
• It should fallback to current state (can be done from util/loadlocation.go)
• Provide the list of TZ, without asking Postgres
• Validate the new list of TZ works in major browsers
• migrate old TZ aliases to their current ones (e.g. US/Central becomes America/Chicago)

[m17ch]

Reminder: When we do implement a fix for this, include a migration that maps deprecated timezones as appropriate (in the case there is existing deprecated timezone data).

[stale]

This issue has been automatically marked as stale because it has not had recent activity.

[dctalbot]

Migration queries have been generated here: https://github.com/target/goalert/compare/tzmigrate
Note - still need to validate correctness. Also, they don't cover all cases e.g. CST6CDT (#1824)

[stale]

This issue has been automatically marked as stale because it has not had recent activity.

[stale]

This issue has been automatically marked as stale because it has not had recent activity.