[FEEDBACK] Be more specific about time zone IDs

[sffc]

registry.md says that time zone IDs are "A valid time zone identifier" with links to LDML and TZDB.

However, LDML and TZDB define two different standards for time zone identifiers: a BCP-47 ID and a longer form string ID. The longer form IANA time zone ID is generally more well understood.

If we keep this function option (#961), it should be restricted to one set of identifiers, probably the TZDB identifiers.

[aphillips]

Note that timeZone is an option, not a function.

However, LDML and TZDB define two different standards for time zone identifiers: a BCP-47 ID and a longer form string ID. The longer form IANA time zone ID is generally more well understood.

I agree with this and, further, think that support for the "Olson" style IDs is what should be promoted for interchange. I am personally opposed to requiring support for the short IDs (I wouldn't object to an implementation, such as ICU, supporting them if it chooses to do so).

This may be a duplicate of #936.

[macchiati]

This is one where we might want 2 optional options:
timezone: must be a well-formed IANA tzid. If valid, must* be interpreted according to the TZDB
short-timezone: must be a well-formed LDML short tzid. If valid, must* be interpreted according to the TZDB, after mapping via LDML mapping to the IANA tzid.

• The must* is tricky, because we don't want to require that an implementation be instantly updated to the latest TZDB. And 'valid' is also tricky for the same reason, when new TZIDs can be added at any time.

[sffc]

+1 on making IANA zone and BCP-47 zone differently named options if we support both.

[aphillips]

I'm not a big fan of the short ids for general interchange. I would be okay with ICU supporting them using an icu: prefix or with timeZone having two value spaces (although that's icky). As I noted before, I would want to make clear that a non-ICU/non-CLDR implementation does not have to implement the short IDs when implementing the Olson ones and that implementing only the short IDs is a terrifically bad idea. I have no problem with making the reference available and gently permitting it, along the lines of:

If the timeZone option is implemented, an implementation MAY also implement the short-timezone option
but SHOULD NOT implement short-timezone on its own.

@macchiati The "MUST" problem for valid/well-formed is tripping over the processing inside the function handler. We generally avoid prescribing this. So we could specify the value space, up to and including that the ID "MUST" be on the list of valid time zones (the stabilized list including the aliases and suchlike). The interpretation really does depend on the implementation. Updates to the TZDB generally don't affect the list of valid IDs, but their meaning can be affected as zone rules are mutated. An MF2 running on an obsolete copy of TZDB will produce date/time artifacts in its formatting, which is not a bug in MF2 or even the "MF2 implementation".

[sffc]

Given that the timeZone option is clearly marked as "Proposed", I think this need not block LDML 47