-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic Partial Location #5644
Comments
I'm not sure if the zone variant calculator is enough. It is only supposed to know about when a time zone switched between metazone or zone variants with a broad stroke, not time zone transitions. I don't see how it could answer the question, "does this time in America/Phoenix differ from the time in America/Denver?" Unless there is a way? I hope I'm missing something. |
The only case where this can happen is if a zone has a different DST offset than the golden zone: https://unicode.org/reports/tr35/tr35-dates.html#goals:~:text=Except%20for%20daylight%20savings%2C%20at%20any%20given%20time%2C%20all%20zones%20in%20a%20metazone%20have%20the%20same%20offset%20at%20that%20time. We can add a |
Oh, hmm, yeah that might work, although it would mean that you get "Mountain Time (Denver)", so basically one bad apple spoils the format for all time zones in that metazone. |
Ah actually |
|
Maybe we just mark America/Phoenix as "strange" (within a certain period of time) and print "Mountain Time (Phoenix)" all year round? |
We probably shouldn't be the ones deciding this. Maybe bring it to CLDR Design WG. |
It would have to be all year round, because without the TZDB we cannot tell whether the golden zone is currently observing DST. We can only tell if an input zone is observing DST because we get an input offset, for the golden zone there is no way for us to get this information.
CLDR wants us to use the TZDB for this. |
CLDR only says: "when the generic non-location format is not specific enough" which very non-specific. |
If TZDB is really the only way to do this, it's not completely out of the picture to make our own annotation in IXDTF. It is allowed in the spec for annotations to be extensible. Something like
where |
* I assume CLDR will tell us to use TZDB for this.
Not a fan of this. This would require it to be an additional field of whatever we settle on in #5533. |
A question Mark asked last time we briefly discussed this, IIRC, was "check what ICU4C does". I haven't checked yet but we should do that. |
ICU requires a full TZDB, so they can do the clever thing. We don't want to ship a full TZDB. |
Yes, but what are they actually doing? |
If the condition isn't derivable from offset plus time zone identity, it's going to need to go somewhere in the input schema. |
Only if we want to do the fancy thing of only giving Phoenix special treatment while Denver is observing DST. If we special-case it year-round that can be derived from the time zone identity. |
Well, even in that case, don't we still need it in the input schema? Either as a unique zone variant, metazone, or additional field? |
1 similar comment
Well, even in that case, don't we still need it in the input schema? Either as a unique zone variant, metazone, or additional field? |
We can mark |
I'm assuming we land on the approach in #5533 where the metazone and zone variant remain calculated by icu_timezone, meaning this would still need to be in the interface between FormattableTimeZone and datetime::Formatter |
This is actually way more complex: https://unicode.org/reports/tr35/tr35-dates.html#Contents:~:text=Otherwise%20do%20the,Pacific%20Time%20(Whitehorse)%22 |
Hmm, I must have overlooked that algorithm in the spec. Good news though is that it is based on time zone identity rather than TZDB. |
Generic Partial Location is supposed to be used when the offsets for a zone are ambiguous.
There isn't a clear algorithm in the spec on how to determine this, but I assume one would be roughly:
For example: It is July 1 in America/Phoenix. The metazone is America_Mountain. The golden zone is America/Denver. The offset for America/Denver on July 1 is -6. However, America/Phoenix has an offset of -7. Therefore, use Generic Partial Location.
However, we can't do this type of calculation at formatting time, since it definitely needs the TZDB.
Could we do it via ZoneVariant?
ZoneVariant::Standard
ZoneVariant::StandardStrange
ZoneVariant::Daylight
ZoneVariant::DaylightStrange
and if "StandardStrange" or "DaylightStrange" are used, then we print Generic Partial Location instead of Generic Non-Location when a Generic format is requested.
I think we could probably make the zone variant calculator figure this out, but I haven't thought through all the edge cases yet.
@robertbastian
The text was updated successfully, but these errors were encountered: