What is a time zone?

Thomas Carey tomca at eskimo.com
Tue Feb 13 22:50:19 UTC 2001


Syed - it would seem you'd need a little more (?) to specify hour of
transition. Or do you use Start/EndDate for anything that isn't at midnight?
What do you do for Iran, and for other countries whose calendars do not map
easily to western calendars? Are they always done by reference to
DSTRuleException?

We have a very similar model - but internally we use a human readable 3 or 4
letter acronym (never displayed and so never up for debate - we always
display localized information) which we then use as a parameter to a routine
which uses information like that in DSTRule & DSTRuleException to determine
the offset for computing localtime/GMT transitions. Do you use (a version
of) tzdata as your source of information for determining exceptions to the
rules?

thanks again
tc
----- Original Message -----
From: "Syed Sajjath" <Syed.Sajjath at wcom.com>
Sent: Tuesday, February 13, 2001 2:08 PM
Subject: RE: What is a time zone?


Currently in our application we have two tables,

1) DSTRule:-
RuleName
StartMonth
StartWeek (First, Second, Third, Fourth, Last)
StartDayOfWeek(Sunday)
StartDate(This column is mutually exclusive from previous 3 colums, to
support countries where DST starts and ends on specified dates)
EndMonth
EndWeek
EndDayOfWeek
EndDate

2) DSTRuleException (This stores any exception from the rule for a given
year)
Year
StartDate
EndDate

Regards,
-Syed
-----Original Message-----
From: Thomas Carey

I am certainly interested in consuming such data :)

My question is - what does the "DST rule table" required to augment such a
list look like?

thanks
tc
----- Original Message -----
From: "Syed Sajjath" <Syed.Sajjath at wcom.com>
To: "'Gwillim Law'" <gwil at mindspring.com>; <tz at elsie.nci.nih.gov>
Sent: Tuesday, February 13, 2001 11:50 AM
Subject: RE: What is a time zone?


I work for a conferencing application and our main interest in timezones is
to convert the scheduled conferencing date to a users local time and an
operators local time.  There are two entities involved, the operator and the
conferencing user.  The operator need not be in the same country as the
user.  For example if the user is from India, the operator is in Hong Kong.
When the user schedules the call, he mentions that he wants to schedule a
call at 10:00 am Indian Standard Time.  When the operator gets the
worksheet, (s)he gets the time converted to Hong Kong time, 12:30 PM HKT.
The point I would like to make is the user is, the user knows only his
timezone would be clearer to him if we present IST, India as his timezone
rather than UTC+ 5:30, and when the operator gets the worksheet (s)he is
interested in knowing the time in Hong Kong Time.  I know language is a
barrier, but we do attempt to store what the locals call the timezone, so it
is easier for scheduling in their time.  How do we know IST is for Indian
Standard Time?  We always assosciate the abbreviation with a country, so
when the user is from India IST stands for Indian Standard Time.  Same way
if an Australian user asks for 10:00 am EST, we know it is australian time,
not US.  Whether it is Standart or Summer we calculate based on the
scheduled time(our assumption is user just wants the conference at that
local time).

For this reason, assuming others also have similar applications, I had
requested the tz list to consider having a standardized file with specified
format (only for timezones effective as of now and updated regularly).  John
Halloran (I thank him for the prompt reply) had replied with a list, but
that is not the format I wanted and the list is not complete either.  For
example as pointed out by Alex, Burma is not in the list.  Also there are
two rows for US Eastern Daylight Time and Eastern Standard Time.  I would
like something in the format.

Country , Zone Short Name, Zone Long Name, Standard Short Name, Standard
Long Name, Daylight Short Name, Daylight Long Name, GMT Offset, DST Rule
Name, DST Offset

United States, ET, Eastern Time, EST, Easter Standard Time, EDT, Eastern
Daylight Time, -5:00 , United States, 60 mins.

Is anybody in this maling list interested in such a database or have such an
application?  If so, I would be interested in discussing how they are using
the tzdata, and is there anything we can do together to make maintain our
database in sync with tzdata.  For now I maintain an Oracle database and
manually update the entries.  I have also written my own APIs to support
other programmers needing time conversions.

Regards,
-Syed

-----Original Message-----
From: Gwillim Law [mailto:gwil at mindspring.com]
Sent: Sunday, February 11, 2001 5:56 PM
To: tz at elsie.nci.nih.gov
Subject: What is a time zone?

John Halloran wrote:

> There are good reasons for developing standardized time zone
abbreviations.

I agree.  It would be great to have a worldwide standard, even if not
everyone uses it.  The need has been expressed over and over again in
messages to this mailing list.

But for a worldwide standard to make sense, it would have to define exactly
what a time zone is.  That presents some difficulties.  Different users may
have varying expectations.  The prevalence of the Anglophone North American
paradigm has given rise to certain expectations which may be
self-contradictory.

In the tz database, I think it's pretty clear what a time zone is.  (Now
that I've said that, I'll probably get it wrong.)  'Africa/Algiers', for
example, represents the historical sequence of offsets from UTC to standard
time, as observed in Algiers, and in all other Algerian places that have
observed the same time standard as Algiers continuously since a certain date
(1970, to be specific).  It is understood that if Oran suddenly decided to
go on a different standard time from Algiers, a new time zone would be
created and inserted in the database.

Anglophone North Americans have a strong attachment to a more complicated
concept of time zone.  You all know how it works, but I have to tell you
anyway in order to make my point.  At the most superficial level, the
continent is divided into four geographical areas (and a few extra areas in
the far east and west which don't get much attention).  One of the areas is
called the Eastern Time Zone.  Places in the Eastern Time Zone observe UTC
minus five hours in the winter, which is called Eastern Standard Time, and
UTC minus four hours in the summer, which is called Eastern Daylight Time.

Already a question comes up.  Is the Eastern Time Zone a time zone, whose
attributes include the UTC offsets and common names and abbreviations for
both standard time and daylight saving time?  Probably most people would
like the answer to be 'yes.'  They expect that to solve all their problems.

Looking at it a little more closely, we see that most of Indiana, although
it lies within the Eastern Time Zone, doesn't observe daylight saving time.
That single exception defeats some expectations.  If a computer system knows
only the Eastern Time Zone as originally defined, it will show the wrong
time in Indianapolis during the summer.  The simplest fix is to define an
additional time zone for that section of Indiana.  What should it be called?
Eastern (Indiana) might work.  How about its attributes?  Can we use EST as
an abbreviation for the time in this zone, both summer and winter?  Will
that obliterate distinctions that a computer system needs to make?

People accustomed to the North American system have a strong desire to use
the same name and abbreviations for both the U.S. and Canadian parts of the
Eastern Time Zone.  They're encouraged by the fact that the U.S. and Canada
have started and ended daylight saving time at the same date/time for many
years (since 1976, I think).  They would have wanted to say the same thing
about the U.S. and Mexico, but this year Mexico is changing that.  There's
no reason to assume that Canada will continue to use the same dates as the
U.S., either.  Looking more closely at Indiana, we find that counties and
even smaller areas have different time zone histories, in that they've
chosen to observe DST in some years and not in others.  Counties in Kentucky
have opted to switch from Central Time to Eastern Time.  Do we have to call
them different time zones, or can we use the concept of a time zone that has
variable boundaries?  Is it within the scope of the standard to describe the
boundaries, and their evolution through time?

How about countries that observe the same standard time?  Can they be lumped
into a regional zone, like West Africa Time?  Some countries may object to
being included with their neighbors.  China, Malaysia, the Philippines,
central Indonesia, and other areas are all on a year-round standard time
that's UTC plus eight hours.  What time zone name would be equally
acceptable to all of them?

It might be easier to approach these questions from the other end, asking,
what functionality do we want to support?  Most users want to have a set of
short tags that can be appended to a time, and that indicate its offset from
UTC.  The ISO 8601 tags (+-hh[:mm]) would suffice for that purpose.  If
anyone is not satisfied with ISO 8601, they must want to convey more
information than just the offset from UTC.  What useful information is
imparted by EST (or CDT), that isn't imparted by -05:00?  It carries some
information about the location, but I don't see much use for that
information.  We don't even know whether Wayne County, Kentucky is in
Eastern or Central unless we know the date and have an extensive lookup
table.  The tag EST also carries some information about the season, and it
implies a rule for start and end of daylight saving time, but again, I don't
see the usefulness.  As far as I can tell, the only benefit to using EST or
a similar abbreviation is in the human interface, and there it's just a
question of comfort, not of essential information.  Have I missed something?

Suppose that, given any location and any date/time expressed in local time
at that location, you want to compute the corresponding time in UTC (or vice
versa, converting UTC to local time).  I know one way to solve that problem
in general.  You would need the tz database, and a table that maps from
locations to time zones of the 'Africa/Algiers' type.  Is there any simpler
solution based on 'Eastern Time'-type time zones?

In my own experience, the main reason for knowing about time zone tags like
EST is that other companies will often send electronic data containing such
tags, and my company has to interpret them.  As I've explained, the only
useful information they contain is an offset from UTC.  Should there be a
time zone standard that just lists the tags and their corresponding offsets
from UTC?  EST would probably translate to UTC-5, because North America is
the 800-pound gorilla in the room, and Australia doesn't know whether it
means UTC+10 or UTC+11.  It would be hard to choose between an Israeli and
Indian interpretation of IST, so perhaps both of them would be junked in
favor of an ISO 3166-based system, using IL for Israel and IN for India.
Would that be of any benefit to anyone?

This is, of course, an invitation for further discussion.

Yours,    Gwillim Law









More information about the tz mailing list