On 06/03/2016 07:16 AM, Random832 wrote:
the*intent* seems quite clearly to be to favor English-speaking countries
Quite true; tzdata itself has always been English-language, and this favors English-speaking countries. That is why Europe/Berlin uses CEST (the English-language abbreviation for Central European Summer Time) and not MESZ (the German abbreviation for Mitteleuropäische Sommerzeit) for its abbreviation now. Users who want a German translation are encouraged to use CLDR, which addresses that sort of thing. This bias for English in general and a North American time zone abbreviation style in particular comes the API's original design. 7th Edition Unix (1979) supported only English and as shipped ran in US Eastern time with US daylight-saving rules hard-coded in C; if you wanted to run in a different time zone you had to change some code and recompile the system. The 7th Edition 'date' program used the format of "Sat Jan 15 19:23:42 EST 1977" because it was easy in those circumstances. Had the 'date' program not bothered to output the time zone abbreviation, tz and POSIX and ISO C quite probably wouldn't have tried to specify how abbreviations are generated, and we wouldn't have the abbreviation mess we have now. In 7th Edition Unix the "EST" in the above example came from a hard-coded table that had only the five main North American zones (standard and daylight) plus GMT. For what it's worth, if you change 7th Edition's TIMEZONE to Tomsk's time zone and its DSTFLAG to 0 and recompile everything, the 7th Edition 'date' command outputs "Sun Jan 16 07:23:42 GMT+7:00 1977", which is similar in spirit to the "Sun Jan 16 07:23:42 +07 1977" that is output by tzdata 2016d's 'date' command when TZ='Asia/Tomsk'.