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@mindspring.com] Sent: Sunday, February 11, 2001 5:56 PM To: tz@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