Calculate TimeZoneInput from timestamps

[sffc]

Pending #528, we will likely require time zones to be fully resolved into GMT offsets and metazones. However, the reality is that people will want to hand ICU4X a timestamp, and get a localized result out the other end. Our organization has the expertise to implement these conversions, and I think we should release libraries to perform them. Of course, they should be modular and stand to the side of ICU4X.

What we should implement is, I think, rather straightforward:

• Input: Timestamp (seconds since epoch) and BCP-47 time zone identifier*
• Output: Metazone, GMT offset, and variant (input to #528)

* I would like to take the BCP-47 time zone identifier as input because I want to encourage the use of the small, fixed-width, lightweight types within ICU4X. However, since most people will be using IANA identifiers, we should also provide a library on the side that can convert from IANA identifier to BCP-47 identifier.

We should also think about how this relates to the ISO-8601 and Temporal data models. In particular, we may want to match our data model to strings such as:

1. 2021-03-05T07:49:02Z is a timestamp in UTC
2. 2021-03-05T00:49:02-0700 is the same timestamp but with a GMT offset
3. 2021-03-05T00:49:02-0700[America/Denver] is a zoned datetime; the GMT offset should serve as a hint to help resolve potential conflicts near variant transitions (daylight savings time)

In the end, we also need the ISO date to feed into #534, so the time zone resolution layer should make sure to retain that information when possible.

[sffc]

Discussion 2021-03-12:

• This component will need DataProvider and is unlikely to be useful outside the context of ICU4X
• We will release this as an ICU4X utility, living in the ICU4X repo
• This component is more closely tied to ICU4X than, say, TinyStr, so we shouldn't tie this conclusion to conclusions about TinyStr

[sffc]

I think we should seriously consider making a TimeZone class with a similar API as Temporal.TimeZone, which has two benefits:

1. We can follow a pre-existing design
2. Helps ICU4X be a basis for Temporal implementations

Read more: https://github.com/tc39/proposal-temporal/blob/main/docs/timezone.md

CC @nordzilla

[nordzilla]

I will incorporate this into Friday's discussion.

[sffc]

Note that we will want to support both directions. In ICU these are Calendar::setTime and Calendar::getTime.

[robertbastian]

Fixed by https://github.com/unicode-org/icu4x/pull/5349

[sffc]

5349 doesn't let us consume a timestamp, which is the title of this issue. We could decide that this issue is out of scope and close it, but that would be a TC decision; the stated issue is definitely not "fixed by" #5349.

[robertbastian]

Oh sorry, I only saw the IXDTF string in the issue and didn't read it in enough detail.

• Input: Timestamp (seconds since epoch) and BCP-47 time zone identifier*
• Output: Metazone, GMT offset, and variant (input to https://github.com/unicode-org/icu4x/issues/528)

I don't think we want to do this. Going from timestamp + zone identifier to datetime + ~GMT~ UTC offset requires the full TZDB, this is what we want to rely on crates like chrono_tz and jiff for. Going from datetime + zone identifier + UTC offset to metazone and zone variant is implemented. I think this is fixed.

[sffc]

Oh sorry, I only saw the IXDTF string in the issue and didn't read it in enough detail.

• Input: Timestamp (seconds since epoch) and BCP-47 time zone identifier*
• Output: Metazone, GMT offset, and variant (input to Replace metazones with a more compact identifier #528)

I don't think we want to do this. Going from timestamp + zone identifier to datetime + ~GMT~ UTC offset requires the full TZDB, this is what we want to rely on crates like chrono_tz and jiff for.

It is only in the last 14 days that my thinking has shifted toward us taking a path that avoids the full TZDB in ICU4X. I think we should still have the TC discussion to decide on whether this opinion is shared with others.