Cannot reliably restore an input-time-zone's value

[nwhittaker]

Check existing issues

• I have checked for existing issues to avoid duplicates

Actual Behavior

It is not possible to always restore the same value to the input-time-zone component that the user set on it during the previous edit session.

For example, if the user previously selected the "(GMT-6) Easter and Galapagos" option, the next edit session shows the "(GMT-6) Bahia de Banderas, Cambridge Bay, Costa Rica, El Salvador, Managua, Monterrey, and Tegucigalpa" option as selected.

Expected Behavior

The input-time-zone options have unique values that can be used to accurately restore the user's prior selection.

Reproduction Sample

https://codepen.io/nwhittaker-esri/pen/GRaRWbX

Reproduction Steps

1. Visit the sample
2. Select the "(GMT-6) Easter and Galapagos" option from the first input-time-zone
3. Observe the second input-time-zone updates with "(GMT-6) Bahia de Banderas, Cambridge Bay, Costa Rica, El Salvador, Managua, Monterrey, and Tegucigalpa" option instead of the option from step 2.

Reproduction Version

2.8.0

Relevant Info

No response

Regression?

No response

Priority impact

p4 - not time sensitive

Impact

There is admittedly little impact here since the ArcGIS backend stores offsets instead of time zones. However, for consumers who do store time zone information, the input-time-zone component becomes the primary limiting factor.

The repro. is contrived but a more real-world scenario is using a form to edit previously stored time-zone data.

Calcite package

• @esri/calcite-components
• @esri/calcite-components-angular
• @esri/calcite-components-react
• @esri/calcite-design-tokens
• @esri/eslint-plugin-calcite-components

Esri team

ArcGIS Field Apps

[richiecarmichael]

In your example, both "(GMT-6) Easter and Galapagos" and "(GMT-6) Bahia de Banderas, Cambridge Bay..." have (or had) the corresponding value of -360.

This issue is exasperated in populous zones, for example, GMT+3 currently has five entries as shown below.

I would strongly suggest that input-time-zone has one item per numeric offset. For example:

(GMT+2) Longyearbyen
(GMT+3) Athens, Aden, Addis Ababa, Asemera, Cairo,
        Gaza, Jerusalama, Nicisia, Syowa, and Volograd
(GMT+3.5) Tehran
(GMT+4) Astrakhan, Baku, Dubai, Mahe, Mauritius
        Reunion, Ulyanovsk, and other unfamiliar cities