Boruch Baum wrote:
pre-compile a list that suits my parochial needs, and update my list anytime the tzdata package is updated (and still have to occassionally guess or prompt the user).
This seems the wisest course, if you're committed to accepting abbreviations on input. You can automate the trawl through the tzfiles, to pick out the abbreviation meanings that are relevant to your application. Run the program once, each time tzdata is updated. Then when your application gets an abbreviation as input you do just one quick lookup in the table that you generated. For any more general approach to using abbreviations as input, each specific application still needs to determine its own approach to disambiguation. Maybe it must provide some disambiguating hints, such as a range of years or a continent. Maybe ambiguities should be resolved by asking a human. Also, there's fundamentally more than one thing you can do with an abbreviation as input: do you want to determine a specific geographical timezone, or just an offset? It all depends on the application. So it's not awfully feasible to provide one table that's applicable to most users of abbreviations. Have a look at <https://metacpan.org/release/App-olson>, a querying tool. See what you make of the output from queries like "olson list i@now o@now". It doesn't support searching for an abbreviation anywhere in a time period, but I'm intending to add that in the future. I think some tool like this would be of benefit to abbreviation users. -zefram