great analysis, david. thanks. I think you hit the nail on the head about differences in approach to the problem. Of course in practical terms a simple model has some strengths in terms of user interface. Put another way - most calendaring applications dealing with timezones are concerned with coordinating events now and in the future - and assume further more that it is possible to present an interface which allows users to distinguish between timezones in different locales regardless of whether they might share a common abbreviation in popular usage. Then it is 'just' a matter of completeness to instantiate every timezone in use now, and to keep that current moving forward, while preserving the historical data. Then, given a localtime and a "timezone" (abstracted as a set of rules for computing offset from UTC) we can coordinate events around the globe. In fact it seems like that approach would work for historical events as well - as long as you could identify the timezone. Which is I guess the point you are making - it is much easier to go from locale to "timezone" than vice-versa, even in the present, and even if "timezone" is well defined for the user. Also I can see that you can better support a COMPLETE database with a locale based interface - the interface for exposing *every* enumerated timezone thoughout history would be overwhelming and unappreciated. tc ----- Original Message ----- From: "David Keegel" <djk@cyber.com.au> I think common usage outside this group is that a time zone has variable boundaries, and is something like the set of places which *currently* observe the same time (although perhaps US EST and CDT might be considered different time zones). In this model, counties in Kentucky change time zone, rather than creating a new time zone, when they switch. So translating this mindset to the computer world, if you are in Wayne County you would manually change your $TZ from US/Central to US/Eastern on 2000-10-29. Of course, this simplistic model has a fairly obvious problem. You can't compute times across a discontinuity like that in any sensible way, which is why this group has a different concept of what a time zone is - that it has a history attached and does not have variable boundaries (in theory). Might it reduce this confusion if the TZ group used something like "time zone history" or "time zone ruleset" instead of just "time zone", to distinguish it from the epheremal idea of "time zone" in popular usage? __________________________________________________________________________ David Keegel <djk@cyber.com.au> URL: http://www.cyber.com.au/users/djk/ Cybersource P/L: Unix Systems Administration and TCP/IP network management