[tz] Belarus is listed in MSK timezone

Paul Ganssle pganssle at gmail.com
Sat Apr 25 20:38:36 UTC 2015

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 at 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:

(note "tzname")


(yes, it says

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

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

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

and "XBD Environment Variables" says


        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):


                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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20150425/c7c8568a/attachment.htm>

More information about the tz mailing list