At 11:32 AM 02/09/01 -0600, you wrote:

It would be very helpful for me if there is a separate file with Country Name, short name (like ET), Zone Long Name(Eastern Time), Zone Summer short Name(EDT), Zone Summer Long Name (Eastern DayLight Time), short Name(EST), Zone standard Long Name(Eastern Standard Time) GMT Offset (Standard) Currently used indicator (this will indicate if the timezone is just for historical purposes) Each timezone abbreviation used in the tzdata must be the same as Zone Short Name of the reference file. the aim of tz database is), but all the same it will be very useful for folks who need the data in database format and write their own functions to interpret it. Thanks, -Syed (v.398-4015)

Pasted in here is a complete list of time zones and abbreviations. TimeZones(0) = "Universal Time - UT (00:00)" TimeZones(1) = "West Africa Time - WAT (01:00)" TimeZones(2) = "Azores Time - AT (02:00)" TimeZones(3) = "Brazil Zone 2 - BZT2 (03:00)" TimeZones(4) = "Newfoundland Standard Time - NST (03:30)" TimeZones(5) = "Atlantic Standard Time - AST (04:00)" TimeZones(6) = "Atlantic Daylight Time - ADT (03:00)" TimeZones(7) = "Atlantic War Time - AWT (03:00)" TimeZones(8) = "Eastern Standard Time - EST (05:00)" TimeZones(9) = "Eastern Daylight Time - EDT (04:00)" TimeZones(10) = "Eastern War Time - EWT (04:00)" TimeZones(11) = "Central Standard Time - CST (06:00)" TimeZones(12) = "Central Daylight Time - CDT (05:00)" TimeZones(13) = "Central War Time - CWT (05:00)" TimeZones(14) = "Mountain Standard Time - MST (07:00)" TimeZones(15) = "Mountain Daylight Time - MDT (06:00)" TimeZones(16) = "Mountain War Time - MWT (06:00)" TimeZones(17) = "Pacific Standard Time - PST (08:00)" TimeZones(18) = "Pacific Daylight Time - PDT (07:00)" TimeZones(19) = "Pacific War Time - PWT (07:00)" TimeZones(20) = "Yukon Standard Time - YST (09:00)" TimeZones(21) = "Yukon Daylight Time - YDT (08:00)" TimeZones(22) = "Yukon War Time - YWT (08:00)" TimeZones(23) = "Alaska/Hawaii Standard Time - AHST (10:00)" TimeZones(24) = "Alaska/Hawaii Daylight Time - AHDT (09:00)" TimeZones(25) = "Alaska/Hawaii War Time - AHWT (09:00)" TimeZones(26) = "Hawaiian Standard Time - HST (10:30)" TimeZones(27) = "Hawaiian Daylight Time - HDT (09:30)" TimeZones(28) = "Hawaiian War Time - HWT (09:30)" TimeZones(29) = "Bering Standard Time - BET (11:00)" TimeZones(30) = "Int'l Date Line West - IDLW (12:00)" TimeZones(31) = "Chukot Summer Time - UZ12S (-14:00)" TimeZones(32) = "Chukot Time - UZ12 (-13:00)" TimeZones(33) = "New Zealand Std Summer Time - NZST (-13:00)" TimeZones(34) = "New Zealand Std Time - NZT (-12:00)" TimeZones(35) = "Kamchatka Summer Time - UZ11S (-13:00)" TimeZones(36) = "Kamchatka Time - UZ11 (-12:00)" TimeZones(37) = "New Zealand Summer Time - NZS (-12:30)" TimeZones(38) = "New Zealand Time - NZ (-11:30)" TimeZones(39) = "Okhotsk Summer Time - UZ10S (-12:00)" TimeZones(40) = "Okhotsk Time - UZ10 (-11:00)" TimeZones(41) = "South Australian Summer Time - SDT (-11:30)" TimeZones(42) = "South Australian Time - SAT (-10:30)" TimeZones(43) = "Australian Eastern Daylight Time - AEDT (-11:00)" TimeZones(44) = "Australian Eastern Standard Time - AEST (-10:00)" TimeZones(45) = "Vladivostok Summer Time - USZ9S (-11:00)" TimeZones(46) = "Vladivostok Time - USZ9 (-10:00)" TimeZones(47) = "Australian Central Daylight Time - ACDT (-10:30)" TimeZones(48) = "Australian Central Standard Time - ACST (-09:30)" TimeZones(49) = "Japan Daylight Time - JDT (-10:00)" TimeZones(50) = "Japan Standard Time - JST (-09:00)" TimeZones(51) = "Amur Summer Time - USZ8S (-10:00)" TimeZones(52) = "Amur Time - USZ8 (-9:00)" TimeZones(53) = "Moluccas Time - MT (-08:30)" TimeZones(54) = "Australian Western Daylight Time - AWDT (-09:00)" TimeZones(55) = "Australian Western Standard Time - AWST (-08:00)" TimeZones(56) = "China Daylight Time - CHDT (-09:00)" TimeZones(57) = "China Standard Time - CHST (-08:00)" TimeZones(58) = "Irkutsk Summer Time - USZ7S (-9:00)" TimeZones(59) = "Irkutsk Time - USZ7 (-8:00)" TimeZones(60) = "Java Time - JT (-07:30)" TimeZones(61) = "Yenisei Summer Time - USZ6S (-08:00)" TimeZones(62) = "Yenisei Time - USZ6 (-07:00)" TimeZones(63) = "North Sumatra Time - NSUT (-06:30)" TimeZones(64) = "West-Siberian Summer Time - USZ5S (-07:00)" TimeZones(65) = "West-Siberian Time - USZ5 (-06:00)" TimeZones(66) = "Indian Daylight Time - IDT (-06:30)" TimeZones(67) = "Indian Time - IST (-05:30)" TimeZones(68) = "Ural Summer Time - USZ4S (-06:00)" TimeZones(69) = "Ural Time - USZ4 (-05:00)" TimeZones(70) = "Volga Summer Time - USZ3S (-05:00)" TimeZones(71) = "Volga Time - USZ3 (-04:00)" TimeZones(72) = "Iran Daylight Time - IRDT (-04:30)" TimeZones(73) = "Iran Time - IT (-03:30)" TimeZones(74) = "Moscow Summer Time - MSKS (-04:00)" TimeZones(75) = "Moscow Time - MSK (-03:00)" TimeZones(76) = "Baghdad Daylight Time - BADT (-04:00)" TimeZones(77) = "Baghdad Time - BAT (-03:00)" TimeZones(78) = "Eastern European Daylight Time - EEDT (-03:00)" TimeZones(79) = "Eastern European Time - EET (-02:00)" TimeZones(80) = "Kaliningrad Summer Time - USZ1S (-03:00)" TimeZones(81) = "Kaliningrad Time - USZ1 (-02:00)" TimeZones(82) = "Central European Daylight Time - CEDT (-02:00)" TimeZones(83) = "Central European Time - CET (-01:00)" TimeZones(84) = "British Double Summer Time - BDST (-02:00)" TimeZones(85) = "British Summer Time - BST (-01:00)" Regards, ------------------------------------------- John Halloran, Halloran Software P.O. Box 75713, Los Angeles, CA 90075 U.S.A. http://www.halloran.com/ e-mail: seagoat@primenet.com

Date: Sat, 10 Feb 2001 06:55:01 +1000 From: Greg Black <gjb@gbch.net>

"John A. Halloran" wrote:

...

TimeZones(43) = "Australian Eastern Daylight Time - AEDT (-11:00)" TimeZones(44) = "Australian Eastern Standard Time - AEST (-10:00)"

Although these (and the other Australian names given) seem to be correct,

Actually, as far as I know, Australian legislation does not specify either names or abbreviations for the zones, and various Australians seem to do as they please. John Mackin reported in 1991 that Australian Broadcasting Commission announcers use the phrases `Eastern Standard Time' or `Eastern Summer Time', and that announcers on the overseas service Radio Australia prefix the word `Australian' to these phrases. Some of the other names in that database are questionable, but I'm afraid I don't have time right now to review it carefully.

every Unix TZ setup I've ever seen uses EDT and EST for those zones,

Recent tz databases use 'EST' for both zones; this follows the phraseology reported for ABC.

At 11:02 PM 02/10/01 +0700, Robert Elz <kre@munnari.OZ.AU> wrote:

Date: Fri, 09 Feb 2001 09:50:25 -0800 From: "John A. Halloran" <seagoat@primenet.com> Message-ID: <3.0.6.32.20010209095025.00f12d70@pop.primenet.com>

| Pasted in here is a complete list of time zones and abbreviations.

(with the offsets from UTC conveniently opposite from the conventional method - positive is generally east of Greenwich, and negative west ... except inside unix).

The numbers in the previous list are not UTC offsets. The standard amounts are true time zones. They can all be defined as "Add to get UTC."

| TimeZones(43) = "Australian Eastern Daylight Time - AEDT (-11:00)"

This is quite simply wrong, there is no "Daylight" time in Australia, there is "Summer" time.

The following list of 55 world time zones from an Australian source agrees with you about the name, having "Australian Eastern Summer Time", although in order for it to be unique, the abbreviation is still AEDT. GMT Greenwich Mean Time +00:00 UT Universal Time +00:00 WAT West Africa Time +01:00 AZ Azores Time +02:00 BZT2 Brazil Zone 2 +03:00 NST Newfoundland Time +03:30 AST Atlantic Time +04:00 ADT Atlantic Daylight Time +03:00 EST Eastern Time +05:00 EDT Eastern Daylight Time +04:00 EWT Eastern War Time +04:00 CST Central Time +06:00 CDT Central Daylight Time +05:00 CWT Central War Time +05:00 MST Mountain Time +07:00 MDT Mountain Daylight Time +06:00 MWT Mountain War Time +06:00 PST Pacific Time +08:00 PDT Pacific Daylight Time +07:00 PWT Pacific War Time +07:00 YST Yukon Time +09:00 AHST Alaska-Hawaii Time +10:00 AHDT Alaska-Hawaii Daylight Time +09:00 HST Hawaii Time +10:30 NT Nome Time +11:00 BET Bering Time +11:00 BST British Summer Time -01:00 BWT British War Time -02:00 CET Central European Time -01:00 MET Middle European Time -01:00 EET Eastern European Time -02:00 BAT Baghdad Time -03:00 USZ3 USSR Zone 3 -04:00 USZ4 USSR Zone 4 -05:00 IST Indian Time -05:30 USZ5 USSR Zone 5 -06:00 NSUT North Sumatra Time -06:30 SSUT South Sumatra Time -07:00 JT Java Time -07:30 CCT China Coast Time -08:00 JST Japan Time -09:00 GST Guam Time -10:00 SAT South Australian Time -09:30 SDT South Australian Summer Time -10:30 AEST Australian Eastern Time -10:00 AEDT Australian Eastern Summer Time-11:00 ACST Australian Central Time -09:30 ACDT Australian Central Summer Time-10:30 AWST Australian Western Time -08:00 AWDT Australian Westerm Summer Time-09:00 NZ New Zealand Time (Pre 1940) -11:30 NZT New Zealand Time -12:00 NZST New Zealand Summer Time -13:00 NZS New Zealand Summer (Pre 1940) -12:30 AWT Atlantic War Time +03:00 The Soviet time zone names in the previous e-mail's list, but not the abbreviations, are from a source in Moscow. Here is his letter, dated Dec. 23, 1997.

Dear Mr. Halloran: First of all, as you asked me, I send you herewith my comments concerning your proposed new list of time zones. I agree that it is not necessary to have Moscow Standard Time in the time zones list. I suppose that it in normal to have USSR Time Zones in the list, because most of potential users of the program in countries of the former Soviet Union were born in these time zones. On the other hand I am afraid that it is not quite correct to use such notation for ACTUAL time zones, because some people in Russia and other CIS countries have an aversion for that name already, but most of them just will decide that the program is a little bit antique. Perhaps it will be better to use "Russia" instead of "USSR" for actual time zones or to add also more neutral and universally recognized notation for names of zones: USSR Zone 1 = Kaliningrad Time or Kaliningrad Time Zone (neither USSR or Russia has no Time Zone 1, so legally the Kaliningrad Time is the Moscow Time minus one hour) USSR Zone 2 = Moscow Time (not "Decree" after January 19, 1992, but still -03:00) USSR Zone 3 = Volga Time or Volga Time Zone USSR Zone 4 = Ural Time or Ural Time Zone USSR Zone 5 = West-Siberian Time or West-Siberian Time Zone USSR Zone 6 = Yenisei Time or Yenisei Time Zone USSR Zone 7 = Irkutsk Time or Irkutsk Time Zone USSR Zone 8 = Amur Time or Amur Time Zone USSR Zone 9 = Maritime (or Vladivostok) Time or Maritime (or Vladivostok) Time Zone USSR Zone 10 = Okhotsk Time or Okhotsk Time Zone USSR Zone 11 = Kamchatka Time or Kamchatka Time Zone USSR Zone 12 = Chukot Time or Chukot Time Zone All zones have appropriate Summer Times. Under legislation enacted in 1992, summer time begins at 2 AM on the last Sunday of March and ends at 3 AM on the last Sunday of September. I shell send you details on other question in the nearest future. Regards, Alexei Kornilov

Regards, ------------------------------------------- John Halloran, Halloran Software P.O. Box 75713, Los Angeles, CA 90075 U.S.A. http://www.halloran.com/ e-mail: seagoat@primenet.com

At 04:12 PM 02/11/01 +0700, Robert Elz <kre@munnari.OZ.AU> wrote:

There's no hope (other than by forcing unrelated named) to make timezone name abbreviations unique. Most of us simply recognised that as an impossibility a long time ago. You can impose your own set of abbreviations on whatever you control, but you're not going to convince many others to go along with your set.

A large part of the world don't have names for timezones, let alone abbreviations for them - there is simply "the time", which you can pretend is called "The time in XXX" or "XXX time" for some country name XXX (or region), but that's just you inventing that label.

Numeric zone offsets are easier to manipulate, make just as much sense, and are much less ambiguous. We should just stick to using those.

There are good reasons for developing standardized time zone abbreviations. The abbreviation acts as a key to retrieve a full time zone name that is meaningful to the local user. The abbreviation tells whether the hour in question is standard time or daylight/summer time. With just a numeric hour, you lose that information. If you do go the numeric route, then it should consist of two parts: the standard time zone hour:minutes and the current offset from the standard time zone, whether 0 or -1 or whatever the politicians have in effect. However, you lose the ability to pull up a local name. I see no problem with having more than one abbreviation for a particular zone hour, if that allows retrieval of Israel Standard Time versus Eastern European Time, for example. But, there is competition for certain common abbreviations, such as both Israel and India competing for IST. This is where an organization such as the ISO, with which I have no connections, would need to make the hard choices. There is a parallel with the procedure for arriving at ISO country codes and language codes. To show you what I mean, here is a proposal for ISO language codes that appeared on the Linguist List on Feb. 4, 2000.

1. ISO 639: language codes

ISO 639 is one of many international standards developed by groups of experts in many countries. This section provides a simplified view.

Put simply, ISO 639's job is to provide simple codes that can be embedded in (mainly computerised) information systems that can allow these information systems to highlight language use, or even to enable useful things like font switching or similar, e.g. on Internet web sites.

There are older 2-letter codes used, it could be said, mainly in older, "legacy" system. 3-letter codes (mainly identical with codes used by the Library of Congress, and in many libraries) have seen the largest growth, and allow for greater expansion. Actually the two sets are currently listed in two separate parts of ISO 639, respectively in ISO [WD] 639[-1] and ISO 639-2.

The Internet Engineering Task Force's specification RFC 1766 recommends the use of ISO 639 codes in Internet uses.

We have also been in discussion with the Summer Institute of Linguistics (SIL) who use a different (and much larger) set of 3-letter codes in their Ethnologue, codes which have also been used in some Internet situations. [SNIP] - ---------------------------------------------------------- LC ISO 639-2 ISO 639-1 Language name in English - ---------------------------------------------------------- --- --- --- (aj) Abaza abk ab Abkhazian --- --- --- (ad) Adyge ace Achinese ach Acoli ada Adangme aar aa Afar afh Afrihili afr af Afrikaans afa Afro-Asiatic (Other) aka ak Akan akk Akkadian alb/sqi * sq Albanian ale Aleut alg Algonquian languages --- --- --- (an) Aragonese tut Altaic (Other) amh am Amharic apa Apache languages ara ar Arabic arc Aramaic arp Arapaho [SNIP]

You can see that there is competition for certain abbreviations, and that the choice of who gets what can be arbitrary. But as the creators say, they have tried to follow existing conventions as much as possible. The Unix time zone volunteers have as much right as any to decide on the conventions for computer/Internet time zone reference. Since the list subscribers are representative of the current world spread of computer usage, it would be fair to have nominations for unique abbreviations (from 2 to 5 letters) and tally the votes for and against. Regards, ------------------------------------------- John Halloran, Halloran Software P.O. Box 75713, Los Angeles, CA 90075 U.S.A. http://www.halloran.com/ e-mail: seagoat@primenet.com

matthew green wrote:

from my point of view (as an australian) using "AEST" is wrong. using "AEDT" is *really* wrong. why?

no one here uses those abbreviations.

Instead we use "EST" for everything (based on current Unix implementations), and that's bad for two reasons: * Most software is hard-wired to equate "EST" with -0500. * It does not distinguish at all between NSW, which uses summer time, and Qld, which doesn't. If we could get all mailers being used in Australia to drop the abbreviations altogether and just use offsets, that would work. But it seems improbable that this could happen. Replacing the clearly useless abbreviations with "wrong" but meaningful ones would at least be useful.

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

John Halloran wrote:

...

There are good reasons for developing standardized time zone abbreviations.

I though that was already done by NATO long ago (but apparently now abolished in favour of using Zulu/UTC everywhere): Y = UTC-01:00 YZ = UTC-00:30 Z = UTC ZA = UTC+00:30 A = UTC+01:00 AB = UTC+01:30 B = UTC+02:00 ... or so. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>

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

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 [mailto:tcarey@bluetrain.com] Sent: Tuesday, February 13, 2001 2:23 PM To: Syed.Sajjath@wcom.com; 'Gwillim Law'; tz@elsie.nci.nih.gov Subject: Re: What is a time zone? 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

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

David, I essentially view libtz as a repository of timezone data. We use it for lot more functionality than tzcode offers. For example identify a timezone based on ZIPCODE or phone number. The most beneficial would be for tzdata files to be in a database format. That is, files of specific layout which can be loaded straight into databases. Once loaded into databases the applications can use it in variety of ways, independent of programming language and platform. In fact, I use the data in IBM mainframes, with COBOL routines as well as UNIX machines with C++ routines. By Thomas's responses, I gather he also has similar requirements. I have designed the database for our application, and used tzdata to populate it. The database has the following main tables, Timezone Rules RuleExceptions Country Timezone Assosciation Region timezone assosciation Country Region We can get country and region information from lot of sources, but tzdata is the best for Timezone and Daylight Saving information. It already has all the information required, just not in the right format. Regards, -Syed -----Original Message----- From: David Keegel [mailto:djk@cyber.com.au] Sent: Tuesday, February 13, 2001 4:59 PM To: Syed.Sajjath@wcom.com Cc: 'Thomas Carey'; tz@elsie.nci.nih.gov Subject: Re: What is a time zone? Syed, As a hypothetical question, what would need to be changed in tzcode/tzdata to make libtz suitable for your application? The benefit to you of doing this would be that you wouldn't have to keep updating the DST rule data yourself - it seems like there is always someone in the world wanting to change their DST rules, so doing this properly is a lot of work. Easier to just ftp the latest data every month or two. Even if you don't want to change your application, it may be instructive for us to get a better handle on what people want in the real world that isn't currently in tz, so that the next programmer can use libtz. ] 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 [mailto:tcarey@bluetrain.com] ] Sent: Tuesday, February 13, 2001 2:23 PM ] To: Syed.Sajjath@wcom.com; 'Gwillim Law'; tz@elsie.nci.nih.gov ] Subject: Re: What is a time zone? ] ] 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 __________________________________________________________________________ David Keegel <djk@cyber.com.au> URL: http://www.cyber.com.au/users/djk/ Cybersource P/L: Unix Systems Administration and TCP/IP network management

Indeed there is! The Global Gazetteer has around 4 million places on file, and many of these include area codes and time zone data. I am currently working on trying to resolve some of the rather broad statements in the tz database, in order to assign a canonical name to each place. Best wishes Alan Pritchard The GLOBAL GAZETTEER: the world on file http://www.allm-geodata.com Tel: +44 (0) 1202 417 477

David Keegel said:

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).

Change this to say "currently observe the same time and intend to do so for the indefinite future" and you eliminate that problem. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8371 1138 Internet Expert | Home: <clive@davros.org> | Fax: +44 20 8371 1037 Demon Internet | WWW: http://www.davros.org | DFax: +44 20 8371 4037 Thus plc | | Mobile: +44 7973 377646

John A. Halloran wrote:

There are good reasons for developing standardized time zone abbreviations.

There are also good reasons to not do that.

The abbreviation acts as a key to retrieve a full time zone name that is meaningful to the local user.

I agree the ultimate goal is to have a full expression. Where I am unsure is whether abbreviations is the correct way to go. For example, in France (where we are less common with timezones, and also where abbreviations are less common than they are in English), the abbreviations for the timezones (resp. "T.U. + 1" and "T.U. + 2") are much less understood than the full expression is.

The abbreviation tells whether the hour in question is standard time or daylight/summer time.

No. Your own idea of abbreviation do that. But you can conceive abbreviations which do not. Look after Australian example. Or you are really asking for a standardization of the U.S. American system? But did you consider HAE, HNA, etc.? ;-)

With just a numeric hour, you lose that information.

1) there is a solution for that (appending a tag A or B, used in Germany some years ago); 2) the information is redondant with the date; 3) I do not really see the use of it. When I am in Western Spain, in Winter (Standard Time, you'll say), the sun is more ahead of the clock than it is when I am in Eastern Germany in Summer (Daylight Time, you'll say). So the place is at least as much important as the abbreviation, here.

If you do go the numeric route, then it should consist of two parts: the standard time zone hour:minutes and the current offset from the standard time zone, whether 0 or -1 or whatever the politicians have in effect.

That I completely fail to understand. What is the importance of the "standard time zone"? Why should the Winter be the reference? Particularly since "Daylights Time" lasts more than "Standard Time"? And since the timezones have drifted quite a lot toward West, because our life is less tied to the sun, and we prefer living in the evening than in the morning (at least, this is the point in Europe). Or there is a bias because in English you're using this very word, "Standard". I do not.

I see no problem with having more than one abbreviation for a particular zone hour, if that allows retrieval of Israel Standard Time versus Eastern European Time, for example.

But I do. If you allow that, you are going for the same mess as it is for MIME types or DNS names: everyone will register its own use, and then there will be conflicts (IST, EST) with no real (read, "good") solutions. Also, every softwares will have to record the whole list of registrations, which quickly proves uneasy. Then, you set up servers (like DNS) to sort the mess. (And by the way, these servers will resolve an abbreviation to... the 8601 offset). Also, please keep this phrase in mind as "reference A".

But, there is competition for certain common abbreviations, such as both Israel and India competing for IST. This is where an organization such as the ISO, with which I have no connections, would need to make the hard choices. There is a parallel with the procedure for arriving at ISO country codes and language codes.

There is *no* duplicates in either 3166 and 639. Guess why. Also, the ISO do have a committee in charge of these kind of things. And this committee just released the relevant standard. It is named ISO 8601, and it prescibes... numbers.

To show you what I mean, here is a proposal for ISO language codes that appeared on the Linguist List on Feb. 4, 2000. <snip> You can see that there is competition for certain abbreviations, and that the choice of who gets what can be arbitrary.

Sure. In the past, 'esp' were used for Esperanto (in the LoC, IIRC). This has been changed *before* ISO 639-2 came out, to left space to the obvious, I mean Spanish. This particular example is between some 400-pound apes (to use Gwillim's comparisons), so it was sorted out in the development. But there are still some problems. Since timezones is a moving targets, I expect similar problems to occur, and the "AEDT" is not a very sympathic solution, I believe.

The Unix time zone volunteers have as much right as any to decide on the conventions for computer/Internet time zone reference. Since the list subscribers are representative of the current world spread of computer usage, it would be fair to have nominations for unique abbreviations ^^^^^^ You remember "reference A"? Now I do see a problem!

(from 2 to 5 letters) and tally the votes for and against.

If you insist on unique abbreviations, I do have a solution for the EST contention: stay with their Australian meaning, and then use the French Canadian usage for the America: HNE would then mean +0500, and HAE +0400. And this is a parallel with ISO: I should highlight that it is very instructive of the way ISO would solve the problem: Canada might vote for this proposal, Australia too, and Europe (which basically does not care about the whole story) might help Canada and Australia, leaving the USA alone against such a proposal. And of course, such a standard will gain exactly zero acceptance in the USA, but who cares? What about ISO 31, anyway? ;-) Antoine

Quoth Martin Smoot on Mon, Feb 12, 2001:

This is not like the commercial airports around the world where the 3 letter designation has to be unique so your luggage does not get lost (or maybe that is why it does get lost!).

Airports, BTW, have not only unique abbreviations, but also generalized geographical abbreviations which allow you to get a ticket to, say, Paris without specifying an airport. When I went from LON to TYO, I actually went from LHR to NRT. HTH. With timezones it's different. You try to go to IST (Israel), you arrive to IST (India), and your baggage waits for you in IST (Ireland). And I don't see a way to change it without getting out of sync with governments. While I don't think Israel has official English TZ abbreviations, governments in English speaking countries will not change TZ names. Vadik. -- XVII: Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the Second Law of Thermodynamics, i.e., it always increases. -- Norman Augustine

Alex LIVINGSTON wrote:

At 14:07 +0100 2001-02-12, Antoine Leca wrote:

...

3) I do not really see the use of it. When I am in Western Spain, in Winter

<snip>

You mean "When I am in western Spain in winter (standard time, you'll say), the _clock_ is more ahead of the _sun_ [more than an hour and a half] than it is when I am in eastern Germany in summer (daylight time, you'll say) [about an hour].".

Thanks for the correction!

PS:

You might have chosen eastern Poland as your second location, <2nd snip> (But perhaps you're never in Poland or Norway. :-) )

Yes, the very reason!

The breadth of the European central time zone (more than three and a half hours) rivals that of all-one-time-zone China. I understand, however, that in Spain, lunch is at three in the afternoon

That depends according to the latitude (and the season). When you go northern, and this appears to apply to the whole Western continental Europe as far as I understand, lunch time and dinner time seems to be earlier, on a general basis. Now Spain obviously have late lunch and dinner time, anyway. 3 pm seems to me a good first guess in Summer (i.e. you can present yourself in any restaurant at this time, you won't be fire out for *this* reason). 2:30 is a better guess in Winter time, by the way.

(that is when the lunch-time TV news is broadcast), and all other daily activities are correspondingly "postponed",

This particularly affects the Summer, after lunch activities. Spaniers in Summer (for reason related to the conjonction of sun and dry climate) tend to have a looooong rest period between 12 o'clock and, say, 5-6.

thus nullifying the effect of the far-advanced clock. This suggests the possibility of dividing the world into a few broad time zones, with schedules adjusted within them according to relative longitude.

I do not believe it will work, because of the transition points: the very point for exceptions like Indiana and the like, apart form the willingness to differentiate themselves from the Central, is that neither of the bordering possibilities are the panacea. In Central Europe this is viewed as a matter of unity _against_ the mosaic of different states with different laws etc. Europe makes this changing, particularly here in France (Europe is seen as the responsible for our ST/DST system, while in fact this is only partialy true, and avoiding it will be seen by a number of people as a victory against Brussels centralism). Antoine

At 03:07 PM 02/12/01 +1100, Alex LIVINGSTON <alex@agsm.edu.au> wrote:

At 09:50 -0800 2001-02-09, John A. Halloran wrote:

...

Pasted in here is a complete list of time zones and abbreviations.

Certainly not complete, by far. Where's Nepal, Lord Howe Island, the Chatham Islands, Burma (a.k.a. Myanmar), Cocos Islands, Norfolk Island, Marquesas Islands, Tonga, Fiji, Afganistan, ...?

...

TimeZones(41) = "South Australian Summer Time - SDT (-11:30)" TimeZones(42) = "South Australian Time - SAT (-10:30)"

Where did these come from?

Alex Livingston, Thank you for drawing my attention to these special time zone locations. My list has a couple of holes, but not as many as you suggest. You mention Lord Howe Island and then ask where South Australian Time with a standard of -10:30 comes from. Lord Howe is the only Australian location that observes South Australian Time. The daylight saving offset appears to have changed however from one hour to half an hour in 1985. There is an Australian time zone for this offset, but the abbreviation would not correlate to the correct standard time zone. Myanmar/Burma and the Cocos Islands, both standardized at -6:30, are in the list as North Sumatra Time. Norfolk Island at -11:30 is standardized to what the list calls New Zealand Time. The Marquesas Islands in French Polynesia at -9:30 are standardized to what the list calls Australian Central Standard Time. The list certainly does not have the -12:20 standard of Tonga before 1968, but it does have its -13:00 standard since then. The list calls that Chukot Time. Fiji standardized at -12:00 uses the zone that the list calls New Zealand Standard Time. Afghanistan is standardized at -4:30, which is in the list as Iran Daylight Time. Afghanistan could have its own zone. Nepal at -5:45 since 1986 is not in the list. I was not aware of the Chatham Islands east of New Zealand and east of the International Date Line at -12:45 and -13:45 in summer. Since politicians create time zones, there could always be new exceptions to any attempt to freeze the world time zone situation in a comprehensive list. And I do agree with some commentators that trying to force world time zones into tidy boxes may come from an American mindset conditioned by American time zone practices. If the politicians can change the daylight offset from 1 hour to 1/2 hour, it would take awhile for a new abbreviation to percolate to the surface that would reference that daylight time zone. But for any case where a program cannot match the time zone amount to a known time zone name, the program will just call it Local Time and will proceed merrily on its way. The numeric amount is primary. Abbreviations and names must be stored with their numeric amounts, and abbreviations tested mainly to identify the desired zone name when more than one named zone has the specified numeric amount. Zone names are important for the human interface, to be matched and linked to when possible. Don't discount the importance of the human interface. In recognition of it, the trend for data exchange now consists of human readable, meaningful XML element tags, as opposed to obscure fixed field record formats that require a computer to make sense of them. Regards, ------------------------------------------- John Halloran, Halloran Software P.O. Box 75713, Los Angeles, CA 90075 U.S.A. http://www.halloran.com/ e-mail: seagoat@primenet.com

At 02:24 -0800 2001-02-12, John A. Halloran wrote:

You mention Lord Howe Island and then ask where South Australian Time with a standard of -10:30 comes from. Lord Howe is the only Australian location that observes South Australian Time. The daylight saving offset appears to have changed however from one hour to half an hour in 1985. There is an Australian time zone for this offset, but the abbreviation would not correlate to the correct standard time zone.

There is a state of Australia called South Australia. It lies entirely in the current Central time zone of the country. It never, ever observed -11:30 as an offset, and it never observed -10:30 as a "standard" offset. Lord Howe Island lies in the Pacific east of Australia's Eastern time zone and two time zones away from South Australia, having about as close a geographical relationship to South Australia as Bermuda does to Texas. How intelligible (to humans) is "South Australian Time", then, as an offset tag for the time on Lord Howe Island? How are people supposed to know that it does _not_ relate to South Australia?

Myanmar/Burma and the Cocos Islands, both standardized at -6:30, are in the list as North Sumatra Time.

Not used in north Sumatra for decades. How meaningful is that?

Norfolk Island at -11:30 is standardized to what the list calls New Zealand Time.

You mean "New Zealand Time (pre 1940)". I think you'll find that in fact it's pre 1947. And who would relate that offset tag to Norfolk Island?

The Marquesas Islands in French Polynesia at -9:30 are standardized to what the list calls Australian Central Standard Time.

The Marquesas Islands are on what you call +09:30 (UT-09:30), not -09:30. They lie in the eastern Pacific, nowhere near central Australia.

The list certainly does not have the -12:20 standard of Tonga before 1968, but it does have its -13:00 standard since then. The list calls that Chukot Time.

Another generally unhelpful name.

Fiji standardized at -12:00 uses the zone that the list calls New Zealand Standard Time.

And another.

Afghanistan is standardized at -4:30, which is in the list as Iran Daylight Time. Afghanistan could have its own zone.

Nepal at -5:45 since 1986 is not in the list.

I was not aware of the Chatham Islands east of New Zealand and east of the International Date Line at -12:45 and -13:45 in summer.

But the Chatham Islands, though east of 180 degrees longitude (and thus in the western hemisphere), are _west_ of the date line, which necessarily diverges from the 180-degree meridian to lie east of the Chatham Islands. Closer (presumably) to home, you've also left out Newfoundland Daylight Time (+02:30). Please pardon my indignant tone :-) . --Alex

On Fri, 9 Feb 2001, Syed Sajjath wrote:

I have a request regarding zone names. It would be very helpful for me if there is a separate file with Country Name, Zone short name (like ET), Zone Long Name(Eastern Time), Zone Summer short Name(EDT), Zone Summer Long Name (Eastern DayLight Time), Zone standard short Name(EST), Zone standard Long Name(Eastern Standard Time) GMT Offset (Standard) Currently used indicator (this will indicate if the timezone is just for historical purposes)

In what language? See the comments in the europe file on MEZ / CET (different language names for the same zone). -- Joseph S. Myers jsm28@cam.ac.uk

Christoph I think not too farfetched. The OS supplied tz functions are inadequate for the most robust real-world multi-timezone scenarios that modern applications must support. But it depends how closely linked your application is to a particular platform. If you run only on windows, then I think it makes sense to use their routines and timezones, out of the box, so that you integrate well with other windows applications and the OS. probably same on unix. One way to support multi-platforms would be to write to your own api which would wrap the OS supplied routines and data. The problem as you know comes if you need to share data between platforms. The other, more radical, approach is to decide which locales/eras you need to support and make sure that you have the correct information (in some form) and the functions to access it. This will probably be a subset of tzdata (or may have information from some other source, in some other format). Perhaps you'll want rules for the transition, rather than a lookup table for the transition in particular years. There are many different ways of solving the problem. Make sure yours meets the needs of your customers. (The only difficulty I have had with the rule-based solution is with the rules for daylight savings transition in Tehran, which starts the first day of Farvardin and ends the first day of Mehr. I just don't know what to do with that information, so I had to instantiate the dates for this timezone.) (see http://webexhibits.org/daylightsaving/g.html for a non-comprehensive list of DST rules for different timezones.) The only caveat I'd give is not to be overly attached to a complete and eternally correct piece of timezone coordinating software. The nature of the beast is it (or its data) needs to be tweaked occaisionally. Which leads to my last point. Let me note, in the words of an esteemed colleague, that "Political time is a drag." But, it pays the bills. tc ----- Original Message ----- From: "Christoph Bugel" <cbugel@netvision.net.il> To: "Thomas Carey" <tcarey@bluetrain.com> Cc: <srinivas@broadsoft.com>; "Time Zone Mailing List (E-mail)" <tz@elsie.nci.nih.gov> Sent: Friday, February 09, 2001 11:27 AM Subject: Re: TZ database content Interesting. We were thinking about a similar approach, in our case we did not necessarily care about having identical names. Rather, we want to use the tzcode implementations of localtime() and mktime() instead of the ones provided with the OS(**), This would then require us to have tzdata around, and since our code must work windoze as well, we need to provide a tzdata with the product. (tzcode can't read from the registry :). (**) the reason we thought about using localtime() and mktime() from tzcode instead of the C library is that we need to have thread safe code that can work simultaneously with different timezones. Normally this would require doing putenv("TZ") all the time, which causes too much trouble for thread safety. basically we want something like: struct tm *my_localtime(const time_t *time, struct TZ * tz); - i.e., some sort of explicit timezone parameter.. same goes for mktime. I wonder if this is too far fetched. On Fri 2001-02-09, Thomas Carey wrote:

Srini - I have found it necessary to take exactly this approach, incorporating one "snapshot" of the TZ data into our product itself so that it would work properly everywhere. (our web application takes local time from the user's computer, but requires explicit (or implicit) selection of the timezone in effect for each entity to which a timezone applies.)

tc ----- Original Message ----- From: Srinivas Nagaraj To: Time Zone Mailing List (E-mail) Sent: Friday, February 09, 2001 9:02 AM Subject: TZ database content

The TZ (zoneinfo) database comes installed with several operating systems like Linux, Solaris, etc.

I have noticed the content of the TZ database varies between different versions of the same operating system and also between operating systems. This could have been because of when a snapshot of the TZ database was taken.

Ofcourse, one significant difference is the actual name of the time zone. Depending on the content of the TZ database, the time zone name look different. Is it because the TZ database has evolved?

I also noticed that the zone.tab file is not distributed on a number of installations. Was that operating system installation decision?

Now my main question, is it an appropriate application specific common practice to use an application specific TZ database? That way the time zone names can be consistent, irrespective of where the application is installed?

Thank you.

Srini

What is the zone.tab file?

It is a TZ zone descriptions file containing a list of supported time zones by the TZ database. It contains the country code, latitude/longitude of the zone's principal location, zone name as used by the TZ environment variable, and comments. I think this file is useful when building a list of all supported time zones. Srini -----Original Message----- From: Alan Perry [mailto:esprit@jps.net] Sent: Friday, February 09, 2001 2:58 PM To: srinivas@broadsoft.com Cc: Time Zone Mailing List (E-mail) Subject: Re: TZ database content I used to be the guy who did the zoneinfo updates for Solaris. We used the TZ database, but, for some reason never explained to me, we had our own version of the TZ code in libc. I ported the command line utilities, but didn't really get it right. I left Sun in mid '97 and I was still getting queries about the code from my former coworkers almost three years later. One of the pains in updating the database was that the TZ naming conventions would change and had to apply changes to ensure backwards compatibility with older releases of Solaris. Also, we were not including all compiled timezone entries. This was a Solaris packaging issue. The TZ database were included in the core Solaris package and at one time there was a requirement that the core package fit on a single Sun 207 Meg HDs. When I first updated the TZ database (which had not been updated in a while), the size of the compiled TZ entries tripled to over half a Meg, so I had some explaining to do. What is the zone.tab file? I don't remember that. alan

Srinivas Nagaraj wrote:

The TZ (zoneinfo) database comes installed with several operating systems like Linux, Solaris, etc.

I have noticed the content of the TZ database varies between different versions of the same operating system and also between operating systems. This could have been because of when a snapshot of the TZ database was taken.

Ofcourse, one significant difference is the actual name of the time zone. Depending on the content of the TZ database, the time zone name look different. Is it because the TZ database has evolved?

I also noticed that the zone.tab file is not distributed on a number of installations. Was that operating system installation decision?

Now my main question, is it an appropriate application specific common practice to use an application specific TZ database? That way the time zone names can be consistent, irrespective of where the application is installed?

Thank you.

Srini