at the risk of pouring more gas on a fire i don't even care about... fwiw, here's what Android has for the Australia/ zones, courtesy of CLDR via icu4c: Australia/ACT: AEST/AEDT Australia/Adelaide: ACST/ACDT Australia/Brisbane: AEST/AEST Australia/Broken_Hill: ACST/ACDT Australia/Canberra: AEST/AEDT Australia/Currie: AEST/AEDT Australia/Darwin: ACST/ACST Australia/Eucla: ACWST/ACWST Australia/Hobart: AEST/AEDT Australia/LHI: LHST/LHDT Australia/Lindeman: AEST/AEST Australia/Lord_Howe: LHST/LHDT Australia/Melbourne: AEST/AEDT Australia/NSW: AEST/AEDT Australia/North: ACST/ACST Australia/Perth: AWST/AWST Australia/Queensland: AEST/AEST Australia/South: ACST/ACDT Australia/Sydney: AEST/AEDT Australia/Tasmania: AEST/AEDT Australia/Victoria: AEST/AEDT Australia/West: AWST/AWST Australia/Yancowinna: ACST/ACDT // as produced by the following code, run by AOSP's host dalvikvm on Ubunutu, using tzdata2012g and icu4c 4.8. import java.util.*; public class Tz { public static void main(String[] args) { for (String id : TimeZone.getAvailableIDs()) { if (!id.startsWith("Australia/")) continue; TimeZone tz = TimeZone.getTimeZone(id); System.out.println(id + ": " + tz.getDisplayName(false, TimeZone.SHORT, Locale.US) + "/" + tz.getDisplayName(true, TimeZone.SHORT, Locale.US)); } } } on Android, i ignore the abbreviations that come with tzdata and get them from icu4c, since i (a) need localized variants (Europe/Berlin, for example, is useful in a variety of European languages, not just German), and (b) need long display names (such as "Australian Central Standard Time") which i have to get from icu4c anyway. i think the only thing tzdata has over CLDR here is that last i looked, CLDR didn't have the historical names (though it does for currencies). why am i apparently being a dick and not providing a simple diff of CLDR versus tzdata so we can all see what other zones (if any) there are differences in? because icu4c makes it awkward for me to get abbreviations for "non-local" zones. for example, in en_US, i get: Europe/Moscow: GMT+03:00/GMT+03:00 though i do get "Moscow Standard Time" as the long name. i haven't checked, but it might be that icu4c does offer me an abbreviation here, but i refuse to use it because it's already been taken. i jump through some number of hoops to maximize the number of abbreviations i support -- mainly for those poor souls stuck trying to parse dates because some incompetent is squirting ambiguous "human readable" dates between computers -- but i refuse to output an abbreviation that i couldn't unambiguously parse back. i'm not sure how useful my round-trip guarantee is in practice, but it seemed like a good way to limit the insanity. so, yeah, i support far fewer abbreviations [in en_US] than tzdata does [in en_US], but i make up for it in every other locale :-) On Sun, Oct 21, 2012 at 4:25 AM, Edwin Groothuis <edwin@mavetju.org> wrote:
On 21/10/12 04:30 , Paul Eggert wrote:
I took the liberty of doing these tests too:
19,200,000 "EST" site:.au 22,700,000 "AEST" site:.au
So I checked the pages returned for EST. It wasn't until page 42 that the first reference of EST with regarding to the timezone was there. And the second one at page 53.
While going through this list, I've learned a lot of different meaning for word "EST", in all its possible variations in spell capitalization. And the last page, 71 in my case, has 5 of the 10 links related to non-timezone related usage of the string EST.
On the other hand, because of the uniqueness of the string "AEST" (i.e. the four letters aren't used anywhere except where to indicate the timezone), you have 22,700,00 real hits, while you have 19,200,000 hits on a word which usage highly varies.
Edwin
-- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ NIO, JNI, or bionic questions? Mail me/drop by/add me as a reviewer.