You are correct, we do offer two timezones EST(no daylight Savings) and EST(with daylight Saving) in Australia for the user to select. Sometimes, users schecule conference in another timezone, and we cannot always depend on the users to know the current time at that location . For example, a user flying to the United states may request a conference to be scheduled in US Central Time (while he is still in Australia), and has no knowledge of what the local time in US Central time(he will eventually when he lands there), or is Daylight Savings in effect or not. All he will say is, I request a conference call on Feb, 21, 2001 at 10:00 am in US Central time. There is a problem when within a country, there are differrent interpretations of the timezone abbreviations (these are very few, I think Australia is the only place). In the tz list, there are representatives from many countries, and people knowledgeble of local traditions. Their inputs would be very valuable in setting up a list of timezone abbreviations and names, known and used locally. Please forgive me if my arguments are not coherent / clear. But I hope you get the gist of my request. I am sure it would be valuable to lot of tzdata users. For now, I would like to know how many are interested. If the tz list does not want to be filled with responses, you can just reply to me and I will summarize it for the list. So far, I have got response from Thomas Carey, who is also interested in such a file. Regards, -Syed -----Original Message----- From: Eric Ulevik [mailto:eau@ozemail.com.au] Sent: Tuesday, February 13, 2001 4:03 PM To: Syed.Sajjath@wcom.com; 'Gwillim Law'; tz@elsie.nci.nih.gov Subject: Re: What is a time zone?
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).
Of course, this isn't enough. Right now, in Sydney EST means Eastern Summer Time and in Brisbane EST means Eastern Standard Time. A simple solution to scheduling in the near future would be to determine the current difference between UTC and the user's local time. The comprehensive solution requires the user to specify their location. Regards, Eric Ulevik