Also copyrights notwithstanding (but still mportant), considering that metaZones.tzt file that Paul included in the message to which I am replying, as a "source of truth" is laughable. tzdata isn't perfect, though it (at least until a couple of years ago) always strived to have the best known data available to us. That file contains nonsense: "Australia:Brisbane"{ { "Australia_Eastern", } } "Australia:Sydney"{ { "Australia_Eastern", } } That cannot be right, the times in Brisbane and Sydney (right now) aren't the same - they cannot possibly (whatever the rest of that data actually means) be treated the same. We also see: "Australia:Hobart"{ { "Australia_Eastern", } } which is less bad right now, as Hobart's and Sydney's clocks, today, are the same - but they haven't always been, not even back to 1970. The same issue applies to: "Australia:Adelaide"{ { "Australia_Central", } } "Australia:Darwin"{ { "Australia_Central", } } The clocks in Darwin and Adelaide (right now) are not the same either. I haven't checked all of the rest of it, but if just this sample is this bad, why would anyone want to even consider distributing this stuff? Note that the next version of POSIX has extended its definition of TZ (or will have, after it is completed, approved, and published) in a way that allows both America/New_York and Australia:Adelaide (and many other possibilities) to be valid TZ strings (it still allows leading ':' strings for implementation defined specifiers) - but it requires that such timezones contain accurate zone data for all transitions since the epoch (1970-01-01T:00:00:00Z) and encourages providing the best possible data for older times. That is, implementations must map Australia:Darwin into Australia/Darwin if using tzdata, not to Australia/Adelaide, and similarly Australia/Sydney Australia/Brisbane and Australia/Hobart must refer to 3 different transition lists. kre