It is not recommended to directly expose the textual time zone identifier for that reason. CLDR for example provides a mapping from the tzid to the translated name, and that can be tailored. In case your client doesn't like that internal identifier, the correct response would be abolishing the textual time zone identifier (there has been multiple attempts so far).
I wrote a dismissive comment, but I'm curious on why you think its possible not to expose TZ.
There are a lot of contexts in which I need to know the TZ. Logs are a really common one (though they should be in UTC). Calendars are the most common.
I've seen a few calendar systems that default to the invite sender's TZ. I needed to know TZ to appropriately schedule my calendar.
> I'm curious on why you think its possible not to expose TZ.
I didn't meant that. I'm dissecting the problem into two cases here: for end users it is always possible to replace the tzid with labels (possibly tailored) so tzid doesn't have to be exposed at all, and for developers it is required to abolish textual tzids. The latter would require the cooperation and concensus from tzdb's (and contributors') part.
> I've seen a few calendar systems that default to the invite sender's TZ. I needed to know TZ to appropriately schedule my calendar.
For recurring events, you absolutely need to know the TZ. You have teams in the Bay Area and London (common for many tech companies). You are in SF and have a recurring meeting with London on Monday mornings. The meeting today (Sep 27) is at 10AM, or 6PM London time. At what time will the meeting be on Nov 1?
