Steven Abner wrote:
even go one step further, Denver in July output the 12:00 MST, convert it for use in Denver. mktime() is required to handle this and will output 1:00 MDT,
You seem to be confusing input with output here. Your use cases have generally been inconsistent and unlikely. I think you need to spend some time delineating exactly what situation you're trying to address.
Clear example is my incorrect knowledge of GMT.
GMT is not at all exceptional in the relevant respect, of referring to a specific offset rather than to a civil timezone. MST (aside from a Moscow-based interpretation) refers specifically to UT-7h, not to the dance that clocks perform in Denver. Likewise, MDT refers specifically to UT-6h. To accurately represent GMT and BST (as used in the UK) and MST and MDT (as used in north America) in the timezone database, you'd need essentially: Zone GMT 0:00 - GMT Zone BST 1:00 - BST Zone MST -7:00 - MST Zone MDT -6:00 - MDT and similarly for rather a lot of the other abbreviations. (It so happens that two of these four hypothetical zones are already in the database (GMT and MST), but that's unusual among the abbreviations.) If you don't do this, but instead have just links such as BST -> Europe/London, then at best it's still necessary to search within the timezone data to find out what the abbreviation means. That's not actually representing the abbreviation's meaning; it's a bad implementation of the hypothetical abbreviation-to-candidate-zone index. (Bad largely because it can only show one candidate zone per abbreviation.) (Note: I'm not taking a position here on whether abbreviation-based zones should be added the database in principle.) -zefram