Certainly I didn't mean dropping it from the database. It's just that the MSK time zone abbreviation is new, so we can go back to what we were using before, or use the XXX convention mentioned in earlier emails.

My understanding is that FET was dropped because that was something Paul just made up, but given that MSK is not in common use and it's ambiguous, it's not really a good replacement.

I think using BYT makes the most sense because it follows an existing standardized nomenclature (which is probably the next best choice when the descriptive approach comes up empty) and because it's more descriptive of the actual time zone (it applies to all of Belarus uniformly, so no need to single out Minsk).


On Apr 24, 2015, at 2:25 PM, Paul Ganssle <pganssle@gmail.com> wrote:

> I have to say, I was originally very skeptical about this proposal because it seems like it would be political, but if MSK really isn't used locally, it probably shouldn't be in the DB regardless of the political implications, particularly if a identical abbreviation is used elsewhere.
>
> I think that dropping out entirely could work,

"Dropping out" as in "remove Minsk time from the database", which wouldn't work very well for users in Belarus, or "dropping out" as in "don't supply any abbreviation", which wouldn't work very well for those UN*X mechanisms that supply time zone abbreviations:

        http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html (note "tzname")

        http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzname.html

(yes, it says

        The tzset() function shall set the external variable tzname as follows:

                tzname[0] = "std";
                tzname[1] = "dst";

        where std and dst are as described in XBD Environment Variables.

and "XBD Environment Variables" says

        TZ

        This variable shall represent timezone information. The contents of the environment variable named TZ shall be used by the ctime(), ctime_r(), localtime(), localtime_r(), strftime(), mktime(), functions, and by various utilities, to override the default timezone. The value of TZ has one of the two forms (spaces inserted for clarity):

                :characters
        or:

                std offset dst offset, rule

        If TZ is of the first format (that is, if the first character is a <colon>), the characters following the <colon> are handled in an implementation-defined manner.

with the latter being an escape hatch put in for the benefit of the Olson database and code, as it was called back then, so one *could* try arguing that POSIX would not impose any constraints on what we do with tzname[] with a tzdb zone setting, but, in practice, that argument will probably fall on deaf ears).