This is a complex topic. The logic today is simple: if two identifiers are different strings, they are different time zones, even if their rules are the same. If we break this logic, it's unclear where to put the boundary and why.

I agree that what you're showing is unintuitive. Yet where does the unintuitiveness stop? Is it intuitive that TimeZone.UTC is also not equal to TimeZone.of("Etc/UTC")? Is it intuitive that TimeZone.of("UTC") is not equal to TimeZone.of("Etc/UTC")? If the answer to both is no, they should be equal, then should TimeZone.of("GMT"), TimeZone.of("GMT+0"), TimeZone.of("GMT-0"), TimeZone.of("GMT0"), TimeZone.of("Greenwich"), TimeZone.of("UCT"), TimeZone.of("UTC"), and the corresponding Etc/ versions also all be equal?

In the timezone database, there is a notion of timezone aliases (different names for the same thing), but the problem is, some timezones that are aliases today may well stop being equal after a political change, so even this is not correct in general: usually, we need to faithfully preserve the string passed to of. Special-casing some time zones like the plethora of names for UTC to work around the inherent complexity of the timezone databases also doesn't feel right.

I hear you on the complexity of this topic in general, but the specific example seems fixable. Why is the identifier of TimeZone.UTC not "UTC"? That seems like it would be a simple fix for this issue without wading into other problems around zone equality. Or if there are other reasons to keep the identifier as "Z", why not rename the constant to TimeZone.Z?

Oh, ok, I misunderstood your question, then. So, it's okay that TimeZone.of("UTC") doesn't equal TimeZone.of("Z"), the only problem is that TimeZone.UTC.id is not "UTC", right?

Yes, that's correct.