Should TimeZoneInfo::LocalTime be an absolute time?

[sffc]

It seems there would be problems near a transition to determine what metazone to use.

It looks like some of our data is already in UTC offsets. For example:

    "globy": {
      "1981-03-29 02:00": 62,
      "2024-03-31 01:00": 63
    },

From what I can tell, the metazone changed on 2024-03-31 at 00:00 local time, which was 01:00 UTC. (It changed from -0100 East Greenland Standard Time to -0100 [West] Greenland Summer Time, so the metazone changed, but not the offset.)

CC @robertbastian

[robertbastian]

Metazone periods are also in local time, which is why I made offset periods use local time. We made the decision that all our APIs accept local time, in order to support inputs like 2024-09-12T02:00:00[Europe/Zurich] without bundling a TZDB.

The data might be buggy, but it is intended to be in local time.

[robertbastian]

Oh these are metazone periods. Well, good thing I made them human readable, we can debug now.

[robertbastian]

From what I can tell, the metazone changed on 2024-03-31 at 00:00 local time

And what did you tell that from? metaZones.xml disagrees (those are local times):

<timezone type="America/Scoresbysund">
	<usesMetazone to="1981-03-29 02:00" mzone="Greenland_Central"/>
	<usesMetazone to="2024-03-31 01:00" from="1981-03-29 02:00" mzone="Greenland_Eastern"/>
	<usesMetazone from="2024-03-31 01:00" mzone="Greenland"/>
</timezone>

[sffc]

• @robertbastian Often we don't have the offset/absolute time. You need this for generic zone mapping, too, not just specific zone mapping.
• @sffc Maybe it can encode the time as a local time with offset. We'd need to change the serialized data type which is currently "minutes since local epoch".
• @robertbastian Looking at metazones.xml, America/Louisville changes at 0700, so it is probably in UTC, unlike we assumed. But it seems easy enough to change this in datagen.

Conclusion: OK to make this 2.0-stretch