Fw: What is a time zone?
tcarey at bluetrain.com
Wed Feb 14 17:05:16 UTC 2001
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
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
----- Original Message -----
From: "David Keegel" <djk at 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
David Keegel <djk at cyber.com.au> URL: http://www.cyber.com.au/users/djk/
Cybersource P/L: Unix Systems Administration and TCP/IP network management
More information about the tz