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