"A case could be made for translating the native time zone names (Waktu Indonesia Barat, Waktu Indonesia Tengah, and Waktu Indonesia Timur) into English and using abbreviations based on the translated names." That is exactly what the current abbreviations are. Perhaps abbreviating Indonesia to two letters instead of one is the answer (that would yield WIDT, CIDT, and EIDT using the ISO code). This has its own difficulty, however, in that the D could be misread as standing for "daylight." Maybe tweak the word order and use IWT, ICT, and IET?

Date: Wed, 13 May 2009 09:28:45 +0100 From: Tim Diggins <tim@red56.co.uk> Message-ID: <1A8A4692-467F-454A-9C9F-15102C556D0F@red56.co.uk> | Maybe I'm missing something - can someone explain what the | abbreviations are used for They're just part of the standard output data that the ctime() related functions are expected to provide. As you noted, the abbreviations themselves are essentially useless, and applications using them for any more than decoration are generally broken, but what applications decide to do is outside our control. A TZ abbreviation has been available from libc essentially forever, and we need to keep on providing one. kre

Date: Thu, 14 May 2009 11:56:33 +0100 From: Tim Diggins <tim@red56.co.uk> Message-ID: <79758C11-AD60-45D1-B8D1-6D99B743368C@red56.co.uk> | If I have followed what you're saying, shouldn't the tzdata make sure | to use abbreviations that are already current, where these exist, | rather than inventing new ones? Perhaps - wherever they're already current in English anyway (there's so much more that we don't do as part of this project to deal with other languages, and cultures.) If there are places where an English tz abbr is really well defined (so exclude all the Aust stuff where we just keep arguing about what people actually use) and different from what the tz database includes, then we probably need to know about it. | Speaking as an application designer, it's a real shame one can't work | out the 'actual' timezone (as opposed to the current UTC offset) from | the output of formatted time strings, but I suppose there's not a lot | we can do about that now. That's just a matter of the applications outputting enough data do that - so the timezone can be (re-)determined later. The problem is more likely that you want to be able to do it from the same data that is being produced to present to humans, and for that, timezone selection data is unlikely to be included. People just don't want to know that level of detail - all they care about is "what time was it there?" and 'what time was it here?" (or just one of those in some cases) - anything more than that is simply too much information for almost every purpose (calendaring applications often need "what time was it (or will it be) in some random other set of places?" as well of course, but that's all just more of the same. And of course, from just that, there's not enough info to select a timezone, for which we need more than just the relative differences between the local timestamps in two arbitrary places on earth. It doesn't matter how you would encode the extra data, people generally don't want to see it, so it won't be there. Of course, if you have somewhere you can keep data that isn't being used to display to humans, then including the timezone name should be trivial (I'd hope that a calendaring application able to schedule repeating events for a wide area audience would include this kind of thing - as should anything doing long distance timetabling (planes, trains, ...), etc). It would help if we (the world) really had some true standard for timezone names of course. kre

Date: Wed, 13 May 2009 22:31:58 +0700 From: Robert Elz <kre@munnari.oz.au> Message-ID: <5070.1242228718@epsilon.noi.kre.to> | For what it is worth (which is not much) the local (S-E Asia) satellite TV | channels use WIT when they're referring to UTC +07:00 (Jakarta, etc). Apologies, but that was worth even less than I thought it would be ... When I next saw such a reference, it wasn't WIT at all, but WIB, which now I think of it, is what I had always seen (somehow I confused myself last week.) kre