Inconsistencies in TZID values for builtin timezones

[Allen Winter]

On Monday, November 9, 2020 3:03:38 AM EST Milan Crha wrote:
> 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?

Eh.
Let's not break too much at once.
Forget about my rename idea.
> 
> > 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.
> 
Ok. I'll probably remove it in master