Thomas, Thanks for your response. I forgot to include start and end times. For Iran, Israel etc. we always refer to DST Exception. I did extract the data from tzdata files using a script . But had to do lot of manual work also, as some of information needed is in the comment portion of tzdata, and it is not standardized. That is why I have put forth this request. This will help me in ongoing maintenance of the database. Thanks -Syed -----Original Message----- From: Thomas Carey [mailto:tomca@eskimo.com] Sent: Tuesday, February 13, 2001 4:50 PM To: Syed.Sajjath@wcom.com; tz@elsie.nci.nih.gov Subject: Re: What is a time zone? 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@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@wcom.com> To: "'Gwillim Law'" <gwil@mindspring.com>; <tz@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@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