Date: Mon, 26 Jun 2006 14:21:24 -0400 From: "Andy Lipscomb" <AndyLipscomb@decosimo.com> Message-ID: <E3827447A4261D4C80192E07BB7E649102438A39@chaexc01.decosimo.local> | Perhaps a better term would be "historical" time zones. No, time zones including historical information. They're not obsolete. | This would in fact be a useful distinction, since only a relatively | small subset of the timezones are necessary for applications that | look only forward That may be true, but ... | --these would be the first set to present to a user That would be foolish. Users typically select their timezone just once (and certainly they should need to, assuming they don't relocate, and zones don't split - both of which are fairly high visibility activities). If the user selects a zone that seems to work just fine for most applications, but mysteriously gives incorrect answers for that relatively small subset (like anything that prints the modification time of a file that might have been last modified in the past) then we have achieved a poor result. It may be a bit harder to explain, and we may not yet have found the best way to either do that, or allow users to select the correct zone, but doing that additional work at the time when the user is consciously considering the issue is almost certainly going to pay off in the long term. kre