Inconsistencies in TZID values for builtin timezones

[Milan Crha]

On Sat, 2020-11-07 at 09:06 -0500, Allen Winter wrote:
> I also wonder we should replace both
> "freeassociation.sourceforge.net"
> and "citadel.org" with a new identifier like "the.libical.project"
> (or somesuch)

        Hi,
if there are projects like evolution-data-server, whom cache the
timezones, then the rename would double the definitions in the caches
(one timezone definition for the old ID, the other for the new ID, when
a new component is stored). That might not be a problem as such, I
guess. If there is going to be changed the TZID prefix, then I'd use
something short. Would it make sense to use the Location (if filled)
for the TZID in general? It seems it adds come compatibility with other
implementations. For example iCloud uses (and enforces) usage of the
Location as the TZID. Expecting that the implementations can decipher
America/New_York , it should be for good, without a need to pass over
the VTIMEZONE component. Maybe. I doubt projects using Microsoft
timezones can decipher it. I'm not sure of this, maybe I say a complete
nonsense here. I'm sorry.

What about libical.github.com? I suppose the
freeassociation.sourceforge.net had been constructed in a very similar
way.

I can look on the rename, once we agree on the details. By the way, the
rename might make sense only if the client does not use its own TZID
prefix, right?

> I don't see any other specific reason why I made it public.
> If you want to make it private again that's fine with me.

No strong opinion on the icaltzutil_fetch_timezone() from my side. I'll
left the decision up to you.

        Thanks and bye,
        Milan