Hi Dave! Yep, agreed on all counts. Popular libraries are often stuck with
their original behavior forever.
So my advice above (to not canonicalize the user's input time zone
identifier to follow links) is much more practical for new libraries, or
major versions of existing libraries that are OK
> it ought to continue to mean what it meant
> on System V, whether that corresponds to any physical location or
> not.
I have no opinion about what Zone the Link EST5EDT should map to. (Although
I'd be inclined to avoid changing it unless there's a really strong reason
to cause the churn.)
But I
> If you want *permanent standard time* for the UTC-5:00 time zone, that'd
be "EST5",
> which does *not* correspond to a tzdb file; it works as a TZ setting
because the tz code
> parses TZ POSIX/SV-style if it doesn't correspond to a file.
Agree. For this case, Etc/GMT+5 seems like the right zone
I agree with Robert and Mark: adding a new file seems like it adds
unnecessary complexity and will invite incompatibility with some clients.
Is there any downside (other than the work required to patch it) to putting
this ID into `backward`? Would doing so cause a different incompatibility?
Than
