From MPaul5045 at aol.com Mon Aug 3 17:57:19 1998 From: MPaul5045 at aol.com (MPaul5045 at aol.com) Date: Mon, 3 Aug 1998 13:57:19 EDT Subject: Graphic and Cartoon Competition Message-ID: <7795fbbb.35c5fa01@aol.com> Graphic and Cartoon Competition Concours de l'art graphique et de la caricature Grafik- und Karikaturenwettbewerb http://www.zibb.de Grafik- und Karikaturenwettbewerb der Zahntechniker-Innung Berlin-Brandenburg zum Thema "F?r Z?hne gibt es keine Alternative. Aber Ersatz!" Unter dem Motto "Wer gesunde und sch?ne Z?hne hat, f?hlt sich wohl und lacht gern" veranstalteten wir 1996/97 einen gro?en Foto- und Ideenwettbewerb. Weit ?ber 1000 Teilnehmer reichten hierzu ihre Beitr?ge ein. Die Besten wurden pr?miert und sind im Internet (http://www.zibb.de ) unter der Rubrik "Foto- und Ideenwettbewerb" dokumentiert. Mit unserem neuen Grafik- und Karikaturenwettbewerb wollen wir an diese erfolgreiche Aktion ankn?pfen. Machen Sie mit! Teilnahmebedingungen ? Gesucht werden zum Wettbewerbsthema selbst gestaltete Grafiken und Karikaturen. ? Wettbewerbsbeitr?ge k?nnen eingereicht werden in der Zeit vom 1. April bis 30. November 1998. Sie sind zu richten an die: Zahntechniker-Innung Berlin-Brandenburg Alt-Moabit 105, 10559 Berlin. ? Im Wettbewerbszeitraum eingereichte themengerechte Beitr?ge werden in einer monatlichen "Hitliste" im Internet ver?ffentlicht. ? Eine unabh?ngige Jury w?hlt aus den im Internet ver?ffentlichten Beitr?gen im Januar 1999 die besten Arbeiten zur Pr?mierung aus. Die Pr?mierung erfolgt im Februar 1999. ? Die zw?lf besten Beitr?ge werden pr?miert mit: 1. Preis 3.000,00 DM 2. Preis 2.000,00 DM 3. Preis 1.000,00 DM 4.-12. Preis 500,00 DM ? Die Preistr?ger und ihre Beitr?ge werden von Februar bis Dezember 1999 im Internet ver?ffentlicht. ? Die zw?lf pr?mierten Beitr?ge werden voraussichtlich in einem repr?sentativen Wandkalender ver?ffentlicht. ? S?mtliche eingesandten Beitr?ge k?nnen f?r Werbeartikel, wie Brosch?ren und Plakate durch die Zahntechniker-Innung Berlin-Brandenburg genutzt werden. Teilnehmen kann jede Person mit beliebig vielen Beitr?gen. Mit der Einsendung seines Wettbewerbsbeitrags erkl?rt der Teilnehmer sein Einverst?ndnis mit den Teilnahmebedingungen. Die Arbeiten sollten in der Regel im Format DIN A4 (210 x 297 mm) sein, jedoch nicht gr??er als DIN A3 (297 x 420 mm). S?mtliche Beitr?ge m?ssen gut leserlich mit Namen, Adresse, Beruf und Altersangabe versehen sein. Zahntechniker-Innung Berlin-Brandenburg Graphic and Cartoon Competition of the Zahntechniker-Innung Berlin-Brandenburg on the topic "For teeth there is no alternative. But denture!" In 1996/97 we launched a big photo and idea competition. The motto was: "With healthy and beautiful teeth you feel good and like laughing". More than 1000 participants sent in their contributions. The best of them got prizes and can be found in the internet (http://www.zibb.de) under the heading "Foto- und Ideenwettbewerb". We want to continue this successful campaign with our new Graphic and Cartoon Competition. Join the contest! Conditions of participation ? We are looking for illustrations and cartoons, created by the participants, on the subject of the competition. ? Contributions can be sent in from1st April to 30th November 1998. The address is: Zahntechniker-Innung Berlin-Brandenburg (Dental Technicians Corporation Berlin- Brandenburg) Alt-Moabit 105, 10559 Berlin Germany ? All contributions coming in until the deadline will be published in our monthly "Top 10 ..." in the Internet ? An independent jury will chose the best works out of those published in the internet in January 1999. The prizes will be awarded in February 1999. ? Twelve winning contributions will be awarded with: ? 1st prize 3.000,00 DM 2nd prize 2.000,00 DM 3rd prize 1.000,00 DM 4th to 12th prize 500,00 DM ? The winners and their works will be published in the Internet from February to December 1999. ? The twelve wining contributions will probably be published in a representative calendar. ? All contributions can be used for advertising, i.e. for brochures and posters by the Zahntechniker-Innung Berlin-Brandenburg. Anyone can participate with an optional number of pieces of work. By sending in his/her contribution the participant agrees with the conditions of participation. The works should have the regular format DIN A4 (210 x 297 mm) but they should not exceed format DIN A3 (297 X 420 mm). Name, address, occupation and age of the participant are supposed to be on the piece in a readable condition. Concours de l'art graphique et de la caricature organise par la chambre des Zahntechniker-Innung Berlin-Brandenburg sur le sujet ""Il n' y a pas d'alternative aux dents, que des substituts!" En 1996/97 nous avons organis? un grand concours cr?atif et photographique sur le sujet "Celui qui a des dents saines et belles se sent bien et aime rire". Il y avait plus de 1000 participants. Les meilleurs r?sultats ont accord? un prix et ils ont ?t? publi?s sur l'Internet ( http://www.zibb.de) sous la rubrique de "Concours cr?atif et photographique". ? cause du succ?s de cette action nous voulons continuer avec notre nouveau concours graphique et de la caricature. Participez-y! Bonne chance! Conditions de participation ? Nous cherchons des graphiques et caricatures cr?es au sujet du concours. ? La date limite des envois est le 30 novembre 1998. Adressez vos graphiques et caricatures ?: Zahntechniker-Innung Berlin-Brandenburg (Chambre des parodontistes Berlin-Brandenburg) Alt-Moabit 105, 10559 Berlin. Allemagne ? Pendant la p?riode du concours on va publier sur l'Internet les favorites mensuelles. ? En janvier 1999 un jury ind?pendant va choisir les meilleurs r?sultats de toutes les publications sur l'Internet. L'attribution des prix aura lieu en f?vrier 1999. ? Les douze meilleurs participants primeront: ? 1. prix 3.000,00 DM 2. prix 2.000,00 DM 3. prix 1.000,00 DM 4.-12. prix 500,00 DM ? Du f?vrier au d?cembre 1999 les laur?ats et leurs cr?ations seront publi?s ? l'Internet et de surcro?t ? un calendrier mural repr?sentatif. ? Toutes les graphiques et caricatures peuvent ?tre utilis?s aux articles de publicit? comme brochures et affiches par la chambre des m?canicien-dentistes Berlin-Brandenburg. Chacun peut y participer avec un nombre illimit? de propositions. Par l'envoi des cr?ations chaque participant d?clare son accord aux conditions de la participation. Le format des travaux devrait ?tre ? pr?f?rence DIN A 4 (210 sur 297 mm) et pas d?passer le format DIN A 3 (297 sur 420 mm). Indiquez s.v.p. toujours votre nom, l'adresse, la profession et l'?ge. (Chambre des parodontistes Berlin-Brandenburg) Zahntechniker-Innung Berlin-Brandenburg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 30437 bytes Desc: not available Url : http://mm.icann.org/pipermail/tz/attachments/19980803/554400cb/attachment.jpe From Antoine.Leca at renault.fr Wed Aug 5 09:46:04 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Wed, 05 Aug 1998 11:46:04 +0200 Subject: time_t (2000 problem) References: <199808050857.JAA07856@rattle.soton.sc.philips.com> Message-ID: <35C829DC.6B9EF989@renault.fr> Hi, Stephen Baynes wrote: > > > That is a thing I am interested in investigating. > > Are you interested to work in this area (I search after volunteers!) > > > > I would be interested if I had the time. OK. I forgot to point you to the elsie mailing list. In any case, if work is effectively begining, it will take place closely to this group. Do you know it? If not, you might consider subscribing (mail at tz-request at elsie.nci.nih.gov, IIRC). Antoine From stephen.baynes at soton.sc.philips.com Wed Aug 5 10:07:33 1998 From: stephen.baynes at soton.sc.philips.com (Stephen Baynes) Date: Wed, 5 Aug 1998 11:07:33 +0100 Subject: time_t (2000 problem) Message-ID: <199808051007.LAA13346@rattle.soton.sc.philips.com> Antoine.Leca wrote: > > I forgot to point you to the elsie mailing list. > In any case, if work is effectively begining, it will take place > closely to this group. > Do you know it? > I have not heard of it. What is it about? I assume something about time, but is it very specific or very general? Also how much trafic does it carry? > If not, you might consider subscribing (mail at > tz-request at elsie.nci.nih.gov, IIRC). > If it is of interest and does not carry too much trafic, then I will subscribe. Stephen From guy at netapp.com Wed Aug 5 17:58:10 1998 From: guy at netapp.com (Guy Harris) Date: Wed, 5 Aug 1998 10:58:10 -0700 (PDT) Subject: time_t (2000 problem) In-Reply-To: <35C829DC.6B9EF989@renault.fr> from Antoine Leca at "Aug 5, 98 11:46:04 am" Message-ID: <199808051758.KAA25137@tooting.netapp.com> > > > That is a thing I am interested in investigating. What is the thing in question? From moore at cs.utk.edu Thu Aug 6 00:57:06 1998 From: moore at cs.utk.edu (Keith Moore) Date: Wed, 05 Aug 1998 20:57:06 -0400 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Thu, 16 Jul 1998 17:43:53 PDT." <199807170043.RAA11414@shade.twinsun.com> Message-ID: <199808060057.UAA06831@spot.cs.utk.edu> > * A more consistent naming strategy for TZIDs. The current draft is > inconsistent: for the same time zone it sometimes says > "America-New_York", sometimes "America-New York", and sometimes > other things like "Eastern". TZIDs are arbitrary, but a good naming > convention can help reduce the number of errors, ease maintenance, > and improve interoperability. What I'd really like to see is a separate document defining globally-scoped timezone names. That way, TZIDs don't have to be arbitrary. I would think that such a document would want to use a subset of the names in the Olsen database. e.g. "/US/Eastern" > * A reference to the Olson database prior art. Many potential > implementers don't know about this useful source, and have thereby > propagated incorrect time zone data. I agree that this would be useful. > * Allow UTC offsets that are not multiples of one minute. This is > needed for historically recent applications (e.g. the time zone in > Liberia up to 1972). > > * The examples should be a tad more careful about distinguishing > between US Eastern time and New York time, since there was a lot of > confusion about the Eastern time zone before, say, 1976. These also seem appropriate. Keith From Antoine.Leca at renault.fr Thu Aug 6 09:33:44 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Thu, 06 Aug 1998 11:33:44 +0200 Subject: time_t (2000 problem) References: <199808051758.KAA25137@tooting.netapp.com> Message-ID: <35C97878.AD43B662@renault.fr> Guy Harris wrote: > > > > > That is a thing I am interested in investigating. > > What is the thing in question? I am sorry to all you guys at tz list. I did a mistake when privately discussing with Stephen. All right, some more explanations: we had discussions in both news:comp.std.c and the C committee (WG14) about extensions to the Standard C library about time. I am searching people interested to further investigate this area, and I proposed it to Stephen. To improve its knowledge, I give him the address of tz list, which I find is among the most relevant source in this area. But I did it wrong, and I copied the list; hence you received the previous message about it. So, sorry again for annoying everybody here. Best regards, Antoine From mgedmin at pub.osf.lt Fri Aug 7 22:01:36 1998 From: mgedmin at pub.osf.lt (Marius Gedminas) Date: Sat, 8 Aug 1998 00:01:36 +0200 Subject: Time zone update Message-ID: <19980808000136.C651@mg.home> I would like to inform that in this year Lithuanian time zone (Europe/Vilnius) was changed. Here's a diff: -------------- next part -------------- --- europe.orig Thu Sep 4 23:54:16 1997 +++ europe Fri Aug 7 14:05:03 1998 @@ -1526,7 +1526,8 @@ 1:00 C-Eur CE%sT 1944 Aug 3:00 Russia MSK/MSD 1991 Mar 31 2:00s 2:00 1:00 EEST 1991 Sep 29 2:00s - 2:00 C-Eur EE%sT + 2:00 C-Eur EE%sT 1998 Mar 29 2:00s + 1:00 C-Eur CE%sT # From Paul Eggert (1996-11-22): # IATA SSIM (1992/1996) says Lithuania uses W-Eur rules, but since it is # known to be wrong about Estonia and Latvia, assume it's wrong here too. -------------- next part -------------- Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin at pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86 From poleary at amplitude.com Sat Aug 8 21:10:23 1998 From: poleary at amplitude.com (Pete O'Leary) Date: Sat, 8 Aug 1998 14:10:23 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <199808060057.UAA06831@spot.cs.utk.edu> Message-ID: <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> Keith, I assume you mean globally-scoped names together with their corresponding VTIMEZONE component? I think this is a really good idea as well, but it's a fairly signifigant undertaking. There is alot of information in the Olson work than needs to be converted into iCalendar VTIMEZONE format. From the looks of it, this could be done semi-automatically. Any takers? I could be impelled into leading this effort, but I think we'll need to discuss the scope of this in Chicago. Pete. > -----Original Message----- > > * A more consistent naming strategy for TZIDs. The current draft is > > inconsistent: for the same time zone it sometimes says > > "America-New_York", sometimes "America-New York", and sometimes > > other things like "Eastern". TZIDs are arbitrary, but a good naming > > convention can help reduce the number of errors, ease maintenance, > > and improve interoperability. > > What I'd really like to see is a separate document defining > globally-scoped timezone names. That way, TZIDs don't have to be > arbitrary. I would think that such a document would want to use a > subset of the names in the Olsen database. e.g. "/US/Eastern" From moore at cs.utk.edu Sat Aug 8 21:49:54 1998 From: moore at cs.utk.edu (Keith Moore) Date: Sat, 08 Aug 1998 17:49:54 -0400 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Sat, 08 Aug 1998 14:10:23 PDT." <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> Message-ID: <199808082149.RAA16636@spot.cs.utk.edu> > I assume you mean globally-scoped names together with their corresponding > VTIMEZONE component? Yes, that's what I had in mind. But just defining the format of the global timezone names themselves would be a useful first step. (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices. This probably doesn't cover all timezones that one might want to define, but it's a start.) -Keith From eggert at twinsun.com Sat Aug 8 22:52:30 1998 From: eggert at twinsun.com (Paul Eggert) Date: Sat, 8 Aug 1998 15:52:30 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <199808082149.RAA16636@spot.cs.utk.edu> (moore@cs.utk.edu) References: <199808082149.RAA16636@spot.cs.utk.edu> Message-ID: <199808082252.PAA15334@shade.twinsun.com> From: Keith Moore Date: Sat, 08 Aug 1998 17:49:54 -0400 (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices. Why not just stick with the names already in the Olson database, preceded by `/' if necessary for the new standard? The Olson names are widely used existing practice, and I don't see a technical reason to change them. If the ``don't mess with success'' argument is not enough to convince you, then let me explain why the Olson names are the way they are; perhaps that will help. I originally tried using an /XX/yyy style naming convention when I was designing the naming scheme currently used by the Olson database, but I discovered several problems with /XXX/yyy: * Time zone rule boundaries are not well correlated with current political subdivisions. For example, it is tempting to use `/US/IN' for US Eastern Standard Time without DST, as is currently practiced in most of Indiana, but that is incorrect, since part of Indiana _does_ observe DST. * Indiana alone has hundreds of distinct time zone histories, only a few of which are in the Olson database due to its 1970 cutoff; as time goes on, more will need to be added to the Olson database. Even if we identified which subdivisions of Indiana would work for today's time zone histories (which would be a lot of work), the divisions would need to be further subdivided in the future, and this will cause compatibility problems. * The names and boundaries of political subdivisions change too often. Even if we were to come up with names that work today, they would soon become obsolete. It's more stable to choose names that depend as little as possible on politics. * Using political subdivisions injects politics into what should be a technical discussion. To some extent this is unavoidable, but it should be forestalled as much as possible by avoiding political subdivisions in the first place. For these reasons, I used a naming convention that does not try to identify the political boundaries of a time zone rule region. Instead, I used the name of the most populous single location within the region. This method is be less controversial, more stable, and more accurate than trying to name the entire region. This naming regime survived the demise of the Soviet Union without having to rename `Europe/Moscow' or `Asia/Tashkent'; it survived the recent revolution in the Congo without having to worry about its country-code change; and it survived the conflict between India and Pakistan in Kashmir without having to suffer an embargo (unlike Microsoft Windows, which unwisely put political boundaries into its database). It's not infallible; e.g. when Kuybyshev (the most populous city in Russian UTC+4) changed its name back to Samara, the database had to change its name too. But in practice the current Olson scheme has turned out to be more stable than any scheme based on political subdivisions. From eggert at twinsun.com Sat Aug 8 22:57:26 1998 From: eggert at twinsun.com (Paul Eggert) Date: Sat, 8 Aug 1998 15:57:26 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> (poleary@amplitude.com) References: <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> Message-ID: <199808082257.PAA15348@shade.twinsun.com> From: "Pete O'Leary" Date: Sat, 8 Aug 1998 14:10:23 -0700 There is alot of information in the Olson work than needs to be converted into iCalendar VTIMEZONE format. From the looks of it, this could be done semi-automatically. Any takers? On July 16 Antoine Leca wrote that he is doing exactly that, though my impression was that he is doing it automatically, not semiautomatically. You might contact him to see what his current status is. It should be a simple matter of hacking the existing zic parser. From moore at cs.utk.edu Sun Aug 9 02:16:01 1998 From: moore at cs.utk.edu (Keith Moore) Date: Sat, 08 Aug 1998 22:16:01 -0400 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Sat, 08 Aug 1998 15:52:30 PDT." <199808082252.PAA15334@shade.twinsun.com> Message-ID: <199808090216.WAA17388@spot.cs.utk.edu> > From: Keith Moore > Date: Sat, 08 Aug 1998 17:49:54 -0400 > > (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX > is the iso 3166 country code and yyy is a political subdivision > within that country. In many cases just /XX suffices. > > Why not just stick with the names already in the Olson database, > preceded by `/' if necessary for the new standard? The Olson names > are widely used existing practice, and I don't see a technical reason > to change them. Actually, when I suggested that '/' be the introducer for global timezones, I had the Olsen database in mind, and have always assumed that we should start with a subset of that database. But if you're trying to define a standard for global timezone names, it makes sense to think carefully about them and see if you want to keep all of the Olsen timezone names. Some of them don't seem authoritative enough. The Olson database has the (to me) undesirable property that there are a lot of aliases. It seems like we would rather have "canonical" names when possible. And the Olsen database tries to define names for everything. It might be better to not define timezone names where we don't have really good solid authoritative information, or where the local model of calendar doesn't quite fit with what iCalendar does. (like places that use solar time) > I originally tried using an /XX/yyy style naming convention when I was > designing the naming scheme currently used by the Olson database, but > I discovered several problems with /XXX/yyy: > > * Time zone rule boundaries are not well correlated with current > political subdivisions. For example, it is tempting to use `/US/IN' > for US Eastern Standard Time without DST, as is currently practiced > in most of Indiana, but that is incorrect, since part of Indiana > _does_ observe DST. I believe Indiana actually has three different time zones: EST year round EST/EDT (near Cincinnati, OH) CST/CDT (near Louisville, KY) and this varies, as I understand, on a county-by-county basis. (somewhere I have a map of Indiana with different counties shaded according to their timezones) So you clearly can't force everything into clean and easily rememberd political subdivisions - you have to deviate somewhere. I still think it's convenient if *most* of the timezones are easily remembered. (I don't see a problem with the different parts of Indiana using /US/Eastern, /US/Central, and /US/IN/no-dst, as appropriate) > * Indiana alone has hundreds of distinct time zone histories, only a > few of which are in the Olson database due to its 1970 cutoff; as > time goes on, more will need to be added to the Olson database. > Even if we identified which subdivisions of Indiana would work for > today's time zone histories (which would be a lot of work), the > divisions would need to be further subdivided in the future, and > this will cause compatibility problems. How important is it for iCalendar timezones to work before 1998? > * The names and boundaries of political subdivisions change too often. > Even if we were to come up with names that work today, they would > soon become obsolete. It's more stable to choose names that depend > as little as possible on politics. > > * Using political subdivisions injects politics into what should be a > technical discussion. To some extent this is unavoidable, but it > should be forestalled as much as possible by avoiding political > subdivisions in the first place. Well, I suppose we could use long/lat coordinates :) > For these reasons, I used a naming convention that does not try to > identify the political boundaries of a time zone rule region. > Instead, I used the name of the most populous single location within > the region. This method is be less controversial, more stable, and > more accurate than trying to name the entire region. Yes, but what defines a region, and how do people know what region they are in? (or for that matter, how do people know the most populous city in a region?) What timezone should I (in Knoxville, TN) use? Should I say /America/Cincinnati or /America/Atlanta or what? The most populous city within a region still would't suffice to define names for all of Indiana's timezone histories. I realize that there are places where /XX/city works better, (because everybody who is nearby stays in sync with that city's time) but there are also a lot of places in the states for which "Eastern" "Central" "Mountain" and "Pacific" are the obvious names. > This naming regime survived the demise of the Soviet Union without > having to rename `Europe/Moscow' or `Asia/Tashkent'; it survived the > recent revolution in the Congo without having to worry about its > country-code change; and it survived the conflict between India and > Pakistan in Kashmir without having to suffer an embargo (unlike > Microsoft Windows, which unwisely put political boundaries into its > database). It's not infallible; e.g. when Kuybyshev (the most > populous city in Russian UTC+4) changed its name back to Samara, the > database had to change its name too. But in practice the current > Olson scheme has turned out to be more stable than any scheme based on > political subdivisions. No argument there, and yet it would be nice if the names were obvious and guessable. It also seems like whenever there is a political border, we *know* there is a timezone fault-line where if a timezone changes on one side it will change independently of whatever is on the other side. There are of course other fault-lines: borders change, new borders are created, etc., but we can't anticipate everything. Finally, I wonder if the average J. Random Windows user, when asked to specify his timezone, really wants to name a city in another country, even if it is the largest city in his "region". (Note that the Pakistan/India conflict wouldn't have caused a problem anyway, because there was not a dispute about the names of the regions - only the borders of those regions.) Anyway, as I said earlier, I would defer to those with more experience. Keith From eggert at twinsun.com Sun Aug 9 06:27:53 1998 From: eggert at twinsun.com (Paul Eggert) Date: Sat, 8 Aug 1998 23:27:53 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <199808090216.WAA17388@spot.cs.utk.edu> (moore@cs.utk.edu) References: <199808090216.WAA17388@spot.cs.utk.edu> Message-ID: <199808090627.XAA15475@shade.twinsun.com> From: Keith Moore Date: Sat, 08 Aug 1998 22:16:01 -0400 The Olson database has the (to me) undesirable property that there are a lot of aliases. Those aliases are mostly the result of the transition of old-style Olson names (e.g. US/Pacific) to the new-style names (e.g. America/Los_Angeles). Any new standard could omit the old-style names; this would alleviate the problem of aliases. Some of those old names are popular, though.... It might be better to not define timezone names where we don't have really good solid authoritative information, or where the local model of calendar doesn't quite fit with what iCalendar does. If we insist on ``really good solid authoritative information'', then I'm afraid coverage will be limited. Nobody keeps track of this stuff authoritatively on a world-wide basis. Nobody even keeps track of it authoritatively for Indiana! People have called for official bodies to keep track of this stuff authoritatively -- the ISO, or the UN, or the IATA, or somebody. It hasn't happened, and I don't think it likely to happen soon. (like places that use solar time) Nobody uses solar time any more for civil time. The last holdout was Saudi Arabia; they converted to UTC+3 in 1950. I believe Indiana actually has three different time zones: EST year round EST/EDT (near Cincinnati, OH) CST/CDT (near Louisville, KY) and this varies, as I understand, on a county-by-county basis. It's worse than that: the rules were not always uniform within the same county. (I don't see a problem with the different parts of Indiana using /US/Eastern, /US/Central, and /US/IN/no-dst, as appropriate) That doesn't work, because it mishandles time stamps before and after transitions. For example, Starke County, Indiana, switched from CST/CDT to EST on 1991-10-27 (according to the Washington Post that day). So Starke County needs its own unique time zone history. You can't just say that Starke County is EST, because that would mishandle time stamps before the switch; and you can't just say that Starke County is CST/CDT, as that would mishandle timestamps after the switch. How important is it for iCalendar timezones to work before 1998? iCalendar should be able to handle the problems that occurred before 1998, because it's likely that similar problems will occur after 1998. Besides, iCalendar should work for dates before 1998; I'd want to use it that way myself. Why limit it to future dates? I suppose we could use long/lat coordinates :) That would work technically: e.g. instead of `/America/Los_Angeles' you would use `/+340308-1181434' (with ISO 6709 notation for latitude and longitude). I also considered that, but decided against it for a couple of reasons. First, it's unfriendly. Second, I was worried that people might argue about the coordinates (where _is_ the center of Los Angeles, exactly?). what defines a region, and how do people know what region they are in? Ideally, a region would be a maximal set of points all sharing the same time history. A time history would start when standard time was introduced, and would continue to the indefinite future. As time goes on, regions split and the number of regions grows. The Olson database deviates from this ideal by making two concessions to practicality. First, it looks only at time histories since 1970 when determining regions; this greatly reduces the number of regions (which would otherwise be in the thousands). Second, regions never cross current country boundaries; this is a concession to politics that I would have rather avoided from a theoretical point of view, but there were practical arguments for it (see below). Ideally, regions would appear on a map, and someone has actually done this for the Olson database; but I would urge that this not be made part of the standard, for political reasons as well as technical ones. Perhaps you could put the region boundaries into a non-normative annex or whatever the IETF calls that sort of thing. The most populous city within a region still would't suffice to define names for all of Indiana's timezone histories. Why not? There must be at least one location for each unique time history. Just pick the most populous one. Indiana has only 345 unique histories, according to Shanks (1990); each one has at least one town in it. I realize that there are places where /XX/city works better, (because everybody who is nearby stays in sync with that city's time) but there are also a lot of places in the states for which "Eastern" "Central" "Mountain" and "Pacific" are the obvious names. The obvious names don't work once you take into account the fact that cities can change time zones or time zone rules. This happened, for example, to Boise in 1974, to Anchorage in 1983, to Knox, IN in 1991, and to Cancun last year; we can be pretty sure that it will happen again soon to somebody. I wonder if the average J. Random Windows user, when asked to specify his timezone, really wants to name a city in another country, even if it is the largest city in his "region". This isn't a problem, since (as mentioned above) regions never cross current country boundaries in the Olson database. From Markus.Kuhn at cl.cam.ac.uk Sun Aug 9 08:32:47 1998 From: Markus.Kuhn at cl.cam.ac.uk (Markus Kuhn) Date: Sun, 09 Aug 1998 09:32:47 +0100 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Sat, 08 Aug 1998 15:52:30 PDT." <199808082252.PAA15334@shade.twinsun.com> Message-ID: Keith Moore wrote on 1998-08-08: > (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX > is the iso 3166 country code and yyy is a political subdivision > within that country. In many cases just /XX suffices. I have only seen this short excerpt from your mail quoted by Paul on the tz list, so I don't know whether you already know that there exists a new ISO 3166-2 draft standard, which defines ISO alpha codes for regional subdivisions within countries (e.g., the states in US and the bundesl?nder in DE): ISO 3166-1:1997, Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes ISO/DIS 3166-2, Codes for the representation of names of countries and their subdivisions -- Part 2: Country subdivision code ISO/DIS 3166-3, Codes for the representation of names of countries and their subdivisions -- Part 3: Code for formerly used names of countries Paul Eggert replied on 1998-08-08: > Why not just stick with the names already in the Olson database, > preceded by `/' if necessary for the new standard? The Olson names > are widely used existing practice, and I don't see a technical reason > to change them. I agree that naming a time zone after the most populated city within that time zone is a very flexible and sound approach. The only thing that irritates me about the Olson/Eggert tz names is that they are all prefixed by the continent name, which I feel is redundant information. Is there really a good rationale why it has to be "Europe/Berlin" for the German time zone and not just "Berlin". I know that the tz database is structured into several per-continent files, but if we propose these names as a more widely used standard, does the tz source file name really have to be a part of it? If there is not a very good rationale for the continent part of the names used in the tz database and if they are only an implementation kludge for allowing to split the database into several smaller files, then I suggest we consider dropping the continent names quickly (which can certainly be done in some backwards compatible manner). Apart form this detail, the tz database names are certainly the best scheme for naming time zones that I have seen so far and, like Paul, I am very skeptical about inventing a new one based on political boundaries. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: From Antoine.Leca at renault.fr Mon Aug 10 09:56:18 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Mon, 10 Aug 1998 11:56:18 +0200 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt References: Message-ID: <35CEC3C2.B80C955@renault.fr> Markus Kuhn wrote: > > Keith Moore wrote on 1998-08-08: > > (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX > > is the iso 3166 country code and yyy is a political subdivision > > within that country. In many cases just /XX suffices. > > I don't know whether you already know that there exists a > new ISO 3166-2 draft standard, which defines ISO alpha codes for > regional subdivisions within countries (e.g., the states in US and the > bundesl?nder in DE): As Paul explained, this might be inappropriate. For example, the finest degree for Indiana according to ISO DIS 3166-2 is US-IN, and this does not accord with current practice. OTOH, there is Europe or the Western Indies... take a look below! > I agree that naming a time zone after the most populated city within > that time zone is a very flexible and sound approach. The only thing > that irritates me about the Olson/Eggert tz names is that they are all > prefixed by the continent name, which I feel is redundant information. > Is there really a good rationale why it has to be "Europe/Berlin" for > the German time zone and not just "Berlin". First, I should say that I see no reason to invent a new scheme: better to not always reinvent the wheel! Well, my problem is that, *in the view of the iCalendar protocol*, adding a different entry for each country may be an unnecessary burden. So I think that the CET (or MEZ) timezone ought to be named "/Paris" (or "/Berlin", if Berlin is more populated than Paris), instead as the current count: Africa/Ceuta Arctic/Longyearbyen Europe/Amsterdam Europe/Andorra Europe/Belgrade Europe/Berlin Europe/Bratislava Europe/Brussels Europe/Budapest Europe/Copenhagen Europe/Gibraltar Europe/Ljubljana Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Monaco Europe/Oslo Europe/Paris Europe/Prague Europe/Rome Europe/San_Marino Europe/Sarajevo Europe/Skopje Europe/Stockholm Europe/Tirane Europe/Vaduz Europe/Vatican Europe/Vienna Europe/Warsaw (currently questionable) Europe/Zagreb Europe/Zurich to a grand total of 31 entries! Please note that Keith pointed out the number of aliases in the tz database. Paul's answer lead me to think he understood it as the concept of "Link" that is here for backward compatibility reasons. But links are easy to skip; this is not the same game when one has to identify "Europe/London" and "Europe/Lisbon", that have very different history as timezones, but that are now equal, and also equal in the foreseable future. I believe that we should try to keep a minimum number of timezones, at least to not have to worry small implementations, and to keep the requirements on network traffic as small as possible. Antoine From Antoine.Leca at renault.fr Mon Aug 10 09:28:21 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Mon, 10 Aug 1998 11:28:21 +0200 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt References: <199808090216.WAA17388@spot.cs.utk.edu> <199808090627.XAA15475@shade.twinsun.com> Message-ID: <35CEBD35.52828B7F@renault.fr> Keith wrote: > How important is it for iCalendar timezones to work before 1998? and Paul answered: > iCalendar should be able to handle the problems that occurred before > 1998, because it's likely that similar problems will occur after 1998. That is very true. In my eyes, that means that the naming scheme for timezones should be extensible. Right, Paul? > Besides, iCalendar should work for dates before 1998; I'd want to use > it that way myself. Why limit it to future dates? Well, that is another point. In my eyes, we should be able to use the mechanisms described in iCalendar for any use, including in the past (and I hope it successed on this way). OTOH, the aim here is to do a world-wide repository about timezones suitable for Internet scheduling, and here I believe the past problems will be an additional weight with no useful properties. Or should we have two repositories? As you pointed out, my goal is to do an automatic tool that "tranforms" the files at Olson database (tzdata19XXa.tar.gz, not the ones produced by zic) to a database in iCal format (and to Microsoft Win32's format as well). Therefore, be this database served by an Internel protocol, or be it used internaly with proprietary tools is IMHO a personal choice. Antoine From eggert at twinsun.com Mon Aug 10 22:03:14 1998 From: eggert at twinsun.com (Paul Eggert) Date: Mon, 10 Aug 1998 15:03:14 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <35CEBD35.52828B7F@renault.fr> (Antoine.Leca@renault.fr) References: <199808090216.WAA17388@spot.cs.utk.edu> <199808090627.XAA15475@shade.twinsun.com> <35CEBD35.52828B7F@renault.fr> Message-ID: <199808102203.PAA18454@shade.twinsun.com> Date: Mon, 10 Aug 1998 11:28:21 +0200 From: Antoine Leca the naming scheme for timezones should be extensible. Right, Paul? Yes. The number of time regions will increase with time. > Besides, iCalendar should work for dates before 1998; I'd want to use > it that way myself. Why limit it to future dates? the aim here is to do a world-wide repository about timezones suitable for Internet scheduling, and here I believe the past problems will be an additional weight with no useful properties. It might be reasonable for iCalendar to ignore transitions before, say, July 1998 when considering what regions to have in its world-wide repository. This would lower the number of regions considerably. But why bother? The existing tz data gets you back to 1970 for free. It should be slightly more work to start with July 1998 (because you'll have to coalesce regions, select canonical representatives, and so forth) than to start with January 1970 (which should be a simple data translation). Date: Mon, 10 Aug 1998 11:56:18 +0200 From: Antoine Leca "Europe/London" and "Europe/Lisbon", that have very different history as timezones, but that are now equal, and also equal in the foreseable future. That's not a good example, as Europe/London and Europe/Lisbon are currently distinct. Their TZNAMEs differ: Europe/London uses `GMT/BST', whereas Europe/Lisbon uses `WET/WEST'. (Also, when the liberals return to power in Portugal, they may well switch the clocks forward again. :-) However, I agree with your main point: the number of regions will decrease if we drop Europe/Berlin, Europe/Rome, etc. and standardize on Europe/Paris. Would this be acceptable politically, though? As Keith Moore pointed out, J. Random Windows user in, say, Berlin might be a bit upset if he has to point his browser at Paris to set his time zone. I believe that we should try to keep a minimum number of timezones, at least to not have to worry small implementations, and to keep the requirements on network traffic as small as possible. Can you estimate how much would be saved by going with a 1998 horizon versus a 1970 horizon? I don't think it would be all that much, but I don't know what the assumptions are. From olsona at dc37a.nci.nih.gov Tue Aug 11 03:28:35 1998 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NCI)) Date: Mon, 10 Aug 1998 23:28:35 -0400 Subject: tzdata1998g.tar.gz Message-ID: <43E124CC389ED111B18D00805FEA1E63BC4BB2@nihexchange2.nih.gov> The file ftp://elsie.nci.nih.gov/pub/tzdata1998g.tar.gz is now available; it incorporates the Lithuanian change provided by mgedmin at pub.osf.it; it also moves creation of the GMT link with Etc/GMT to "etcetera" (from "backward") to ensure that the GMT file is created even where folks don't want the "backward" links (as suggested by Paul Eggert). --ado From eggert at twinsun.com Tue Aug 11 05:58:30 1998 From: eggert at twinsun.com (Paul Eggert) Date: Mon, 10 Aug 1998 22:58:30 -0700 Subject: pending changes to tz database, mostly from the IATA In-Reply-To: <43E124CC389ED111B18D00805FEA1E63BC4BB2@nihexchange2.nih.gov> (olsona@dc37a.nci.nih.gov) References: <43E124CC389ED111B18D00805FEA1E63BC4BB2@nihexchange2.nih.gov> Message-ID: <199808110558.WAA20753@shade.twinsun.com> I am about to send out changes to the time zone database compiled mostly from data kindly abstracted from the IATA tables by Gwillim Law. Here is a verbal description. Please let me know if any of these changes seem bogus; otherwise, I'll send out a proposed patch shortly. * Quintana Roo switched from CST/CDT to EST/EDT; we assume this happened last fall. This requires a new entry, America/Cancun. * Chihuahua switched from CST/CDT to MST/MDT; we assume this happened this spring. This requires a new entry, America/Chihuahua. * Cuba has changed the rules again. The 1998 change dates are Mar 29 and Oct 25. Thereafter, the rules will be the same as the US, except that the time of switch is 00:00 instead of 02:00. * Haiti stopped observing DST this year. * Starting in 1999, Paraguay switches the last Sunday in February, not March 1. * Starting this year, Estonia uses the EU rules; i.e. it switches at 01:00 UTC (03:00 standard time), not 02:00 standard time. * tzdata1998g.tar.gz has a glitch: it moves the Lithuanian clocks back by an hour at 1998 Mar 29 02:00, waits an hour, and then moves them forward an hour when 02:00 comes by again. Also, the new rules are identical to EU. * Crimea switched from Moscow time back to EET/EEST; we assume it happened in March 1997. * Starting this year, Armenia observes DST again, using the same rules as Russia. * Starting last year, Azerbaijan observes DST, using rules like Russia's except with transition times at 01:00 instead of 02:00. * Starting last year, Kirgizstan adopted DST rules like Russia's, except with transition times at 02:30 instead of 02:00. * Last fall Libya converted from CET/CEST to EET with no DST. Its spring 1997 transition was April 4 at 00:00, not Mar 27 at 02:00. * Egypt's DST rules are the fourth Friday in April at 00:00 to the last Friday in September at 24:00. The current tz database has the rules as the last Friday in April at 01:00 to the last Friday in September at 03:00, due to my transcription errors the last time around. * New Caledonia stopped observing DST in 1997; it was just a 1-year experiment. * The Cook Islands stopped observing DST in 1991. (This claim is from the 1995 edition of Shanks, not from the IATA.) * For the capital of Kazakhstan, the name `Almaty' now has a 2-to-1 majority over the old Russian-derived name `Alma-Ata' in English-language prose, as measured by Alta Vista; so it's time to switch the name in the database, with a backward-compatibility link. From okellyd at logica.com Wed Aug 12 22:12:15 1998 From: okellyd at logica.com (O'Kelly, David) Date: Wed, 12 Aug 1998 18:12:15 -0400 Subject: Lat. / Long to timezone conversion Message-ID: To whom it may concern, I am currently trying to identify if there are any existing software products which can carry out a Latitude / Longitude conversion to the corresponding timezone. Initially I am concentrating on data for the U.S., Canada & Mexico and was wondering if any relevant or pertinent information may be available on this subject. Thank you for any help you can provide. - regards Dave David O'Kelly Principal Software Engineer Communications Division Logica Inc. tel + 1 415 288 5200 fax + 1 415 288 5299 email okellyd at logica.com From rthelen at netapp.com Fri Aug 21 23:16:37 1998 From: rthelen at netapp.com (Randy Thelen) Date: Fri, 21 Aug 1998 16:16:37 -0700 Subject: Possible Bug in INT_STRLEN_MAXIMUM macro Message-ID: <35DDFFD5.B1F1D688@netapp.com> The INT_STRLEN_MAXIMUM macro in lib/private.h used by, among other files, asctime.c, states in its comment field: /* ** 302 / 1000 is log10(2.0) rounded up. ... */ And then in the macro definition we find: #define INT_STRLEN_MAXIMUM(type) \ ... * 302 / 100 ... Me thinks this is not what was intended. Possibly it's an error, possibly it's the right thing. Could you send mail back telling me if this was on purpose? -- Randy Thelen Software Engineer Network Appliance, Inc. From Markus.Kuhn at cl.cam.ac.uk Sat Aug 22 20:51:38 1998 From: Markus.Kuhn at cl.cam.ac.uk (Markus Kuhn) Date: Sat, 22 Aug 1998 21:51:38 +0100 Subject: Revision of ISO C 9x Message-ID: The new ISO C draft is on . I think, the following message might be of interest to many here: ------- Forwarded Message Date: Sat, 22 Aug 1998 21:00:08 +0100 To: David R Tribble , Antoine.Leca at renault.fr, kuhn at cs.purdue.edu From: "Clive D.W. Feather" Reply-To: "Clive D.W. Feather" Subject: It's about time [sorry for the bad joke] I'm sorry I've taken so long to get back to people about this. This email is going to all the people who have expressed to me an interest in the C9X time functions. C9X CD2 (aka the FCD) is now published (it can be found on the DKUUG web site). It basically contains the same material in as CD1 did, though a few minor errors have been corrected and Keld's %O and %E modifiers have appeared. Everyone who's written to me has expressed dissatisfaction with some part or other of the current situation. Therefore I have a rather radical proposal to make: I suggest we write a complete new section that addresses all our issues, and arrange for at least two, and preferably three or more, National Bodies to submit it as part of their response to CD2. I'm willing to act as the core editor for this work, provided: - - people will write full pieces of text for me to drop in as needed; - - people won't object to my use of editorial powers to tidy up and keep the wording consistent. I can provide web space where I will keep the working drafts. I suggest we start with what's in CD2 as a common base, though being ready to drop pieces if that's what we agree. In the meantime, here's all the issues that I'm aware of that our text would need to handle: (1) Clear definition of canonicalisation of times. (2) Unambigous mechanisms for converting between UTC and TAI, and between time zones, and for determining which is in use. (3) Clearer definitions of things like strftime conversions (all of these are in CD2, so this is a no-op). (4) Ability to determine the precision of times (a ticks per second macro, perhaps). This should be guaranteed to be <= 1 second over some range. (5) Ability to determine the range of time_t, with guaranteed minimum limits. (6) A member in struct tmx for access to subsecond resolution, and possibly new formats to access it. (7) The meaning of struct tm to remain source and binary compatible with C89. (8) Clearer definition of what struct tm[x] values must be handled by implementations. (9) All new functions to be re-entrant. (10) Rethink future expandibility of struct tmx. (11) Portable form for transferring time values between programs and implementations. Anything else ? I've no objection to this message having wider circulation, but only to people who aren't going to require more education than there's time for. - -- Clive D.W. Feather | Regulation Officer, LINX | Work: Tel: +44 1733 705000 | (on secondment from | Home: Fax: +44 1733 353929 | Demon Internet) | Written on my laptop; please observe the Reply-To address ------- End of Forwarded Message From olsona at dc37a.nci.nih.gov Mon Aug 24 13:17:34 1998 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NCI)) Date: Mon, 24 Aug 1998 09:17:34 -0400 Subject: Possible Bug in INT_STRLEN_MAXIMUM macro Message-ID: <43E124CC389ED111B18D00805FEA1E63BC4BBC@nihexchange2.nih.gov> -----Original Message----- From: Randy Thelen [SMTP:rthelen at netapp.com] Sent: Friday, August 21, 1998 7:17 PM To: tz at elsie.nci.nih.gov Cc: guy at netapp.com Subject: Possible Bug in INT_STRLEN_MAXIMUM macro The INT_STRLEN_MAXIMUM macro in lib/private.h used by, among other files, asctime.c, states in its comment field: /* ** 302 / 1000 is log10(2.0) rounded up. ... */ And then in the macro definition we find: #define INT_STRLEN_MAXIMUM(type) \ ... * 302 / 100 ... Me thinks this is not what was intended. Possibly it's an error, possibly it's the right thing. Could you send mail back telling me if this was on purpose? -- Randy Thelen Software Engineer Network Appliance, Inc. The bad news is that the macro definition indeed fails to match the comment; the good news is that the error results in over-generous sizing of arrays designed to hold ASCII representations of numbers. I've changed the "100" in the "#define" to the correct "1000"; the change will show up in the next version of tzcode. --ado From MPaul5045 at aol.com Mon Aug 3 17:57:19 1998 From: MPaul5045 at aol.com (MPaul5045 at aol.com) Date: Mon, 3 Aug 1998 13:57:19 EDT Subject: Graphic and Cartoon Competition Message-ID: <7795fbbb.35c5fa01@aol.com> Graphic and Cartoon Competition Concours de l'art graphique et de la caricature Grafik- und Karikaturenwettbewerb http://www.zibb.de Grafik- und Karikaturenwettbewerb der Zahntechniker-Innung Berlin-Brandenburg zum Thema "F?r Z?hne gibt es keine Alternative. Aber Ersatz!" Unter dem Motto "Wer gesunde und sch?ne Z?hne hat, f?hlt sich wohl und lacht gern" veranstalteten wir 1996/97 einen gro?en Foto- und Ideenwettbewerb. Weit ?ber 1000 Teilnehmer reichten hierzu ihre Beitr?ge ein. Die Besten wurden pr?miert und sind im Internet (http://www.zibb.de ) unter der Rubrik "Foto- und Ideenwettbewerb" dokumentiert. Mit unserem neuen Grafik- und Karikaturenwettbewerb wollen wir an diese erfolgreiche Aktion ankn?pfen. Machen Sie mit! Teilnahmebedingungen ? Gesucht werden zum Wettbewerbsthema selbst gestaltete Grafiken und Karikaturen. ? Wettbewerbsbeitr?ge k?nnen eingereicht werden in der Zeit vom 1. April bis 30. November 1998. Sie sind zu richten an die: Zahntechniker-Innung Berlin-Brandenburg Alt-Moabit 105, 10559 Berlin. ? Im Wettbewerbszeitraum eingereichte themengerechte Beitr?ge werden in einer monatlichen "Hitliste" im Internet ver?ffentlicht. ? Eine unabh?ngige Jury w?hlt aus den im Internet ver?ffentlichten Beitr?gen im Januar 1999 die besten Arbeiten zur Pr?mierung aus. Die Pr?mierung erfolgt im Februar 1999. ? Die zw?lf besten Beitr?ge werden pr?miert mit: 1. Preis 3.000,00 DM 2. Preis 2.000,00 DM 3. Preis 1.000,00 DM 4.-12. Preis 500,00 DM ? Die Preistr?ger und ihre Beitr?ge werden von Februar bis Dezember 1999 im Internet ver?ffentlicht. ? Die zw?lf pr?mierten Beitr?ge werden voraussichtlich in einem repr?sentativen Wandkalender ver?ffentlicht. ? S?mtliche eingesandten Beitr?ge k?nnen f?r Werbeartikel, wie Brosch?ren und Plakate durch die Zahntechniker-Innung Berlin-Brandenburg genutzt werden. Teilnehmen kann jede Person mit beliebig vielen Beitr?gen. Mit der Einsendung seines Wettbewerbsbeitrags erkl?rt der Teilnehmer sein Einverst?ndnis mit den Teilnahmebedingungen. Die Arbeiten sollten in der Regel im Format DIN A4 (210 x 297 mm) sein, jedoch nicht gr??er als DIN A3 (297 x 420 mm). S?mtliche Beitr?ge m?ssen gut leserlich mit Namen, Adresse, Beruf und Altersangabe versehen sein. Zahntechniker-Innung Berlin-Brandenburg Graphic and Cartoon Competition of the Zahntechniker-Innung Berlin-Brandenburg on the topic "For teeth there is no alternative. But denture!" In 1996/97 we launched a big photo and idea competition. The motto was: "With healthy and beautiful teeth you feel good and like laughing". More than 1000 participants sent in their contributions. The best of them got prizes and can be found in the internet (http://www.zibb.de) under the heading "Foto- und Ideenwettbewerb". We want to continue this successful campaign with our new Graphic and Cartoon Competition. Join the contest! Conditions of participation ? We are looking for illustrations and cartoons, created by the participants, on the subject of the competition. ? Contributions can be sent in from1st April to 30th November 1998. The address is: Zahntechniker-Innung Berlin-Brandenburg (Dental Technicians Corporation Berlin- Brandenburg) Alt-Moabit 105, 10559 Berlin Germany ? All contributions coming in until the deadline will be published in our monthly "Top 10 ..." in the Internet ? An independent jury will chose the best works out of those published in the internet in January 1999. The prizes will be awarded in February 1999. ? Twelve winning contributions will be awarded with: ? 1st prize 3.000,00 DM 2nd prize 2.000,00 DM 3rd prize 1.000,00 DM 4th to 12th prize 500,00 DM ? The winners and their works will be published in the Internet from February to December 1999. ? The twelve wining contributions will probably be published in a representative calendar. ? All contributions can be used for advertising, i.e. for brochures and posters by the Zahntechniker-Innung Berlin-Brandenburg. Anyone can participate with an optional number of pieces of work. By sending in his/her contribution the participant agrees with the conditions of participation. The works should have the regular format DIN A4 (210 x 297 mm) but they should not exceed format DIN A3 (297 X 420 mm). Name, address, occupation and age of the participant are supposed to be on the piece in a readable condition. Concours de l'art graphique et de la caricature organise par la chambre des Zahntechniker-Innung Berlin-Brandenburg sur le sujet ""Il n' y a pas d'alternative aux dents, que des substituts!" En 1996/97 nous avons organis? un grand concours cr?atif et photographique sur le sujet "Celui qui a des dents saines et belles se sent bien et aime rire". Il y avait plus de 1000 participants. Les meilleurs r?sultats ont accord? un prix et ils ont ?t? publi?s sur l'Internet ( http://www.zibb.de) sous la rubrique de "Concours cr?atif et photographique". ? cause du succ?s de cette action nous voulons continuer avec notre nouveau concours graphique et de la caricature. Participez-y! Bonne chance! Conditions de participation ? Nous cherchons des graphiques et caricatures cr?es au sujet du concours. ? La date limite des envois est le 30 novembre 1998. Adressez vos graphiques et caricatures ?: Zahntechniker-Innung Berlin-Brandenburg (Chambre des parodontistes Berlin-Brandenburg) Alt-Moabit 105, 10559 Berlin. Allemagne ? Pendant la p?riode du concours on va publier sur l'Internet les favorites mensuelles. ? En janvier 1999 un jury ind?pendant va choisir les meilleurs r?sultats de toutes les publications sur l'Internet. L'attribution des prix aura lieu en f?vrier 1999. ? Les douze meilleurs participants primeront: ? 1. prix 3.000,00 DM 2. prix 2.000,00 DM 3. prix 1.000,00 DM 4.-12. prix 500,00 DM ? Du f?vrier au d?cembre 1999 les laur?ats et leurs cr?ations seront publi?s ? l'Internet et de surcro?t ? un calendrier mural repr?sentatif. ? Toutes les graphiques et caricatures peuvent ?tre utilis?s aux articles de publicit? comme brochures et affiches par la chambre des m?canicien-dentistes Berlin-Brandenburg. Chacun peut y participer avec un nombre illimit? de propositions. Par l'envoi des cr?ations chaque participant d?clare son accord aux conditions de la participation. Le format des travaux devrait ?tre ? pr?f?rence DIN A 4 (210 sur 297 mm) et pas d?passer le format DIN A 3 (297 sur 420 mm). Indiquez s.v.p. toujours votre nom, l'adresse, la profession et l'?ge. (Chambre des parodontistes Berlin-Brandenburg) Zahntechniker-Innung Berlin-Brandenburg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 30437 bytes Desc: not available Url : http://mm.icann.org/pipermail/tz/attachments/19980803/554400cb/attachment-0001.jpe From Antoine.Leca at renault.fr Wed Aug 5 09:46:04 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Wed, 05 Aug 1998 11:46:04 +0200 Subject: time_t (2000 problem) References: <199808050857.JAA07856@rattle.soton.sc.philips.com> Message-ID: <35C829DC.6B9EF989@renault.fr> Hi, Stephen Baynes wrote: > > > That is a thing I am interested in investigating. > > Are you interested to work in this area (I search after volunteers!) > > > > I would be interested if I had the time. OK. I forgot to point you to the elsie mailing list. In any case, if work is effectively begining, it will take place closely to this group. Do you know it? If not, you might consider subscribing (mail at tz-request at elsie.nci.nih.gov, IIRC). Antoine From stephen.baynes at soton.sc.philips.com Wed Aug 5 10:07:33 1998 From: stephen.baynes at soton.sc.philips.com (Stephen Baynes) Date: Wed, 5 Aug 1998 11:07:33 +0100 Subject: time_t (2000 problem) Message-ID: <199808051007.LAA13346@rattle.soton.sc.philips.com> Antoine.Leca wrote: > > I forgot to point you to the elsie mailing list. > In any case, if work is effectively begining, it will take place > closely to this group. > Do you know it? > I have not heard of it. What is it about? I assume something about time, but is it very specific or very general? Also how much trafic does it carry? > If not, you might consider subscribing (mail at > tz-request at elsie.nci.nih.gov, IIRC). > If it is of interest and does not carry too much trafic, then I will subscribe. Stephen From guy at netapp.com Wed Aug 5 17:58:10 1998 From: guy at netapp.com (Guy Harris) Date: Wed, 5 Aug 1998 10:58:10 -0700 (PDT) Subject: time_t (2000 problem) In-Reply-To: <35C829DC.6B9EF989@renault.fr> from Antoine Leca at "Aug 5, 98 11:46:04 am" Message-ID: <199808051758.KAA25137@tooting.netapp.com> > > > That is a thing I am interested in investigating. What is the thing in question? From moore at cs.utk.edu Thu Aug 6 00:57:06 1998 From: moore at cs.utk.edu (Keith Moore) Date: Wed, 05 Aug 1998 20:57:06 -0400 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Thu, 16 Jul 1998 17:43:53 PDT." <199807170043.RAA11414@shade.twinsun.com> Message-ID: <199808060057.UAA06831@spot.cs.utk.edu> > * A more consistent naming strategy for TZIDs. The current draft is > inconsistent: for the same time zone it sometimes says > "America-New_York", sometimes "America-New York", and sometimes > other things like "Eastern". TZIDs are arbitrary, but a good naming > convention can help reduce the number of errors, ease maintenance, > and improve interoperability. What I'd really like to see is a separate document defining globally-scoped timezone names. That way, TZIDs don't have to be arbitrary. I would think that such a document would want to use a subset of the names in the Olsen database. e.g. "/US/Eastern" > * A reference to the Olson database prior art. Many potential > implementers don't know about this useful source, and have thereby > propagated incorrect time zone data. I agree that this would be useful. > * Allow UTC offsets that are not multiples of one minute. This is > needed for historically recent applications (e.g. the time zone in > Liberia up to 1972). > > * The examples should be a tad more careful about distinguishing > between US Eastern time and New York time, since there was a lot of > confusion about the Eastern time zone before, say, 1976. These also seem appropriate. Keith From Antoine.Leca at renault.fr Thu Aug 6 09:33:44 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Thu, 06 Aug 1998 11:33:44 +0200 Subject: time_t (2000 problem) References: <199808051758.KAA25137@tooting.netapp.com> Message-ID: <35C97878.AD43B662@renault.fr> Guy Harris wrote: > > > > > That is a thing I am interested in investigating. > > What is the thing in question? I am sorry to all you guys at tz list. I did a mistake when privately discussing with Stephen. All right, some more explanations: we had discussions in both news:comp.std.c and the C committee (WG14) about extensions to the Standard C library about time. I am searching people interested to further investigate this area, and I proposed it to Stephen. To improve its knowledge, I give him the address of tz list, which I find is among the most relevant source in this area. But I did it wrong, and I copied the list; hence you received the previous message about it. So, sorry again for annoying everybody here. Best regards, Antoine From mgedmin at pub.osf.lt Fri Aug 7 22:01:36 1998 From: mgedmin at pub.osf.lt (Marius Gedminas) Date: Sat, 8 Aug 1998 00:01:36 +0200 Subject: Time zone update Message-ID: <19980808000136.C651@mg.home> I would like to inform that in this year Lithuanian time zone (Europe/Vilnius) was changed. Here's a diff: -------------- next part -------------- --- europe.orig Thu Sep 4 23:54:16 1997 +++ europe Fri Aug 7 14:05:03 1998 @@ -1526,7 +1526,8 @@ 1:00 C-Eur CE%sT 1944 Aug 3:00 Russia MSK/MSD 1991 Mar 31 2:00s 2:00 1:00 EEST 1991 Sep 29 2:00s - 2:00 C-Eur EE%sT + 2:00 C-Eur EE%sT 1998 Mar 29 2:00s + 1:00 C-Eur CE%sT # From Paul Eggert (1996-11-22): # IATA SSIM (1992/1996) says Lithuania uses W-Eur rules, but since it is # known to be wrong about Estonia and Latvia, assume it's wrong here too. -------------- next part -------------- Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin at pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86 From poleary at amplitude.com Sat Aug 8 21:10:23 1998 From: poleary at amplitude.com (Pete O'Leary) Date: Sat, 8 Aug 1998 14:10:23 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <199808060057.UAA06831@spot.cs.utk.edu> Message-ID: <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> Keith, I assume you mean globally-scoped names together with their corresponding VTIMEZONE component? I think this is a really good idea as well, but it's a fairly signifigant undertaking. There is alot of information in the Olson work than needs to be converted into iCalendar VTIMEZONE format. From the looks of it, this could be done semi-automatically. Any takers? I could be impelled into leading this effort, but I think we'll need to discuss the scope of this in Chicago. Pete. > -----Original Message----- > > * A more consistent naming strategy for TZIDs. The current draft is > > inconsistent: for the same time zone it sometimes says > > "America-New_York", sometimes "America-New York", and sometimes > > other things like "Eastern". TZIDs are arbitrary, but a good naming > > convention can help reduce the number of errors, ease maintenance, > > and improve interoperability. > > What I'd really like to see is a separate document defining > globally-scoped timezone names. That way, TZIDs don't have to be > arbitrary. I would think that such a document would want to use a > subset of the names in the Olsen database. e.g. "/US/Eastern" From moore at cs.utk.edu Sat Aug 8 21:49:54 1998 From: moore at cs.utk.edu (Keith Moore) Date: Sat, 08 Aug 1998 17:49:54 -0400 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Sat, 08 Aug 1998 14:10:23 PDT." <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> Message-ID: <199808082149.RAA16636@spot.cs.utk.edu> > I assume you mean globally-scoped names together with their corresponding > VTIMEZONE component? Yes, that's what I had in mind. But just defining the format of the global timezone names themselves would be a useful first step. (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices. This probably doesn't cover all timezones that one might want to define, but it's a start.) -Keith From eggert at twinsun.com Sat Aug 8 22:52:30 1998 From: eggert at twinsun.com (Paul Eggert) Date: Sat, 8 Aug 1998 15:52:30 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <199808082149.RAA16636@spot.cs.utk.edu> (moore@cs.utk.edu) References: <199808082149.RAA16636@spot.cs.utk.edu> Message-ID: <199808082252.PAA15334@shade.twinsun.com> From: Keith Moore Date: Sat, 08 Aug 1998 17:49:54 -0400 (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices. Why not just stick with the names already in the Olson database, preceded by `/' if necessary for the new standard? The Olson names are widely used existing practice, and I don't see a technical reason to change them. If the ``don't mess with success'' argument is not enough to convince you, then let me explain why the Olson names are the way they are; perhaps that will help. I originally tried using an /XX/yyy style naming convention when I was designing the naming scheme currently used by the Olson database, but I discovered several problems with /XXX/yyy: * Time zone rule boundaries are not well correlated with current political subdivisions. For example, it is tempting to use `/US/IN' for US Eastern Standard Time without DST, as is currently practiced in most of Indiana, but that is incorrect, since part of Indiana _does_ observe DST. * Indiana alone has hundreds of distinct time zone histories, only a few of which are in the Olson database due to its 1970 cutoff; as time goes on, more will need to be added to the Olson database. Even if we identified which subdivisions of Indiana would work for today's time zone histories (which would be a lot of work), the divisions would need to be further subdivided in the future, and this will cause compatibility problems. * The names and boundaries of political subdivisions change too often. Even if we were to come up with names that work today, they would soon become obsolete. It's more stable to choose names that depend as little as possible on politics. * Using political subdivisions injects politics into what should be a technical discussion. To some extent this is unavoidable, but it should be forestalled as much as possible by avoiding political subdivisions in the first place. For these reasons, I used a naming convention that does not try to identify the political boundaries of a time zone rule region. Instead, I used the name of the most populous single location within the region. This method is be less controversial, more stable, and more accurate than trying to name the entire region. This naming regime survived the demise of the Soviet Union without having to rename `Europe/Moscow' or `Asia/Tashkent'; it survived the recent revolution in the Congo without having to worry about its country-code change; and it survived the conflict between India and Pakistan in Kashmir without having to suffer an embargo (unlike Microsoft Windows, which unwisely put political boundaries into its database). It's not infallible; e.g. when Kuybyshev (the most populous city in Russian UTC+4) changed its name back to Samara, the database had to change its name too. But in practice the current Olson scheme has turned out to be more stable than any scheme based on political subdivisions. From eggert at twinsun.com Sat Aug 8 22:57:26 1998 From: eggert at twinsun.com (Paul Eggert) Date: Sat, 8 Aug 1998 15:57:26 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> (poleary@amplitude.com) References: <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> Message-ID: <199808082257.PAA15348@shade.twinsun.com> From: "Pete O'Leary" Date: Sat, 8 Aug 1998 14:10:23 -0700 There is alot of information in the Olson work than needs to be converted into iCalendar VTIMEZONE format. From the looks of it, this could be done semi-automatically. Any takers? On July 16 Antoine Leca wrote that he is doing exactly that, though my impression was that he is doing it automatically, not semiautomatically. You might contact him to see what his current status is. It should be a simple matter of hacking the existing zic parser. From moore at cs.utk.edu Sun Aug 9 02:16:01 1998 From: moore at cs.utk.edu (Keith Moore) Date: Sat, 08 Aug 1998 22:16:01 -0400 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Sat, 08 Aug 1998 15:52:30 PDT." <199808082252.PAA15334@shade.twinsun.com> Message-ID: <199808090216.WAA17388@spot.cs.utk.edu> > From: Keith Moore > Date: Sat, 08 Aug 1998 17:49:54 -0400 > > (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX > is the iso 3166 country code and yyy is a political subdivision > within that country. In many cases just /XX suffices. > > Why not just stick with the names already in the Olson database, > preceded by `/' if necessary for the new standard? The Olson names > are widely used existing practice, and I don't see a technical reason > to change them. Actually, when I suggested that '/' be the introducer for global timezones, I had the Olsen database in mind, and have always assumed that we should start with a subset of that database. But if you're trying to define a standard for global timezone names, it makes sense to think carefully about them and see if you want to keep all of the Olsen timezone names. Some of them don't seem authoritative enough. The Olson database has the (to me) undesirable property that there are a lot of aliases. It seems like we would rather have "canonical" names when possible. And the Olsen database tries to define names for everything. It might be better to not define timezone names where we don't have really good solid authoritative information, or where the local model of calendar doesn't quite fit with what iCalendar does. (like places that use solar time) > I originally tried using an /XX/yyy style naming convention when I was > designing the naming scheme currently used by the Olson database, but > I discovered several problems with /XXX/yyy: > > * Time zone rule boundaries are not well correlated with current > political subdivisions. For example, it is tempting to use `/US/IN' > for US Eastern Standard Time without DST, as is currently practiced > in most of Indiana, but that is incorrect, since part of Indiana > _does_ observe DST. I believe Indiana actually has three different time zones: EST year round EST/EDT (near Cincinnati, OH) CST/CDT (near Louisville, KY) and this varies, as I understand, on a county-by-county basis. (somewhere I have a map of Indiana with different counties shaded according to their timezones) So you clearly can't force everything into clean and easily rememberd political subdivisions - you have to deviate somewhere. I still think it's convenient if *most* of the timezones are easily remembered. (I don't see a problem with the different parts of Indiana using /US/Eastern, /US/Central, and /US/IN/no-dst, as appropriate) > * Indiana alone has hundreds of distinct time zone histories, only a > few of which are in the Olson database due to its 1970 cutoff; as > time goes on, more will need to be added to the Olson database. > Even if we identified which subdivisions of Indiana would work for > today's time zone histories (which would be a lot of work), the > divisions would need to be further subdivided in the future, and > this will cause compatibility problems. How important is it for iCalendar timezones to work before 1998? > * The names and boundaries of political subdivisions change too often. > Even if we were to come up with names that work today, they would > soon become obsolete. It's more stable to choose names that depend > as little as possible on politics. > > * Using political subdivisions injects politics into what should be a > technical discussion. To some extent this is unavoidable, but it > should be forestalled as much as possible by avoiding political > subdivisions in the first place. Well, I suppose we could use long/lat coordinates :) > For these reasons, I used a naming convention that does not try to > identify the political boundaries of a time zone rule region. > Instead, I used the name of the most populous single location within > the region. This method is be less controversial, more stable, and > more accurate than trying to name the entire region. Yes, but what defines a region, and how do people know what region they are in? (or for that matter, how do people know the most populous city in a region?) What timezone should I (in Knoxville, TN) use? Should I say /America/Cincinnati or /America/Atlanta or what? The most populous city within a region still would't suffice to define names for all of Indiana's timezone histories. I realize that there are places where /XX/city works better, (because everybody who is nearby stays in sync with that city's time) but there are also a lot of places in the states for which "Eastern" "Central" "Mountain" and "Pacific" are the obvious names. > This naming regime survived the demise of the Soviet Union without > having to rename `Europe/Moscow' or `Asia/Tashkent'; it survived the > recent revolution in the Congo without having to worry about its > country-code change; and it survived the conflict between India and > Pakistan in Kashmir without having to suffer an embargo (unlike > Microsoft Windows, which unwisely put political boundaries into its > database). It's not infallible; e.g. when Kuybyshev (the most > populous city in Russian UTC+4) changed its name back to Samara, the > database had to change its name too. But in practice the current > Olson scheme has turned out to be more stable than any scheme based on > political subdivisions. No argument there, and yet it would be nice if the names were obvious and guessable. It also seems like whenever there is a political border, we *know* there is a timezone fault-line where if a timezone changes on one side it will change independently of whatever is on the other side. There are of course other fault-lines: borders change, new borders are created, etc., but we can't anticipate everything. Finally, I wonder if the average J. Random Windows user, when asked to specify his timezone, really wants to name a city in another country, even if it is the largest city in his "region". (Note that the Pakistan/India conflict wouldn't have caused a problem anyway, because there was not a dispute about the names of the regions - only the borders of those regions.) Anyway, as I said earlier, I would defer to those with more experience. Keith From eggert at twinsun.com Sun Aug 9 06:27:53 1998 From: eggert at twinsun.com (Paul Eggert) Date: Sat, 8 Aug 1998 23:27:53 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <199808090216.WAA17388@spot.cs.utk.edu> (moore@cs.utk.edu) References: <199808090216.WAA17388@spot.cs.utk.edu> Message-ID: <199808090627.XAA15475@shade.twinsun.com> From: Keith Moore Date: Sat, 08 Aug 1998 22:16:01 -0400 The Olson database has the (to me) undesirable property that there are a lot of aliases. Those aliases are mostly the result of the transition of old-style Olson names (e.g. US/Pacific) to the new-style names (e.g. America/Los_Angeles). Any new standard could omit the old-style names; this would alleviate the problem of aliases. Some of those old names are popular, though.... It might be better to not define timezone names where we don't have really good solid authoritative information, or where the local model of calendar doesn't quite fit with what iCalendar does. If we insist on ``really good solid authoritative information'', then I'm afraid coverage will be limited. Nobody keeps track of this stuff authoritatively on a world-wide basis. Nobody even keeps track of it authoritatively for Indiana! People have called for official bodies to keep track of this stuff authoritatively -- the ISO, or the UN, or the IATA, or somebody. It hasn't happened, and I don't think it likely to happen soon. (like places that use solar time) Nobody uses solar time any more for civil time. The last holdout was Saudi Arabia; they converted to UTC+3 in 1950. I believe Indiana actually has three different time zones: EST year round EST/EDT (near Cincinnati, OH) CST/CDT (near Louisville, KY) and this varies, as I understand, on a county-by-county basis. It's worse than that: the rules were not always uniform within the same county. (I don't see a problem with the different parts of Indiana using /US/Eastern, /US/Central, and /US/IN/no-dst, as appropriate) That doesn't work, because it mishandles time stamps before and after transitions. For example, Starke County, Indiana, switched from CST/CDT to EST on 1991-10-27 (according to the Washington Post that day). So Starke County needs its own unique time zone history. You can't just say that Starke County is EST, because that would mishandle time stamps before the switch; and you can't just say that Starke County is CST/CDT, as that would mishandle timestamps after the switch. How important is it for iCalendar timezones to work before 1998? iCalendar should be able to handle the problems that occurred before 1998, because it's likely that similar problems will occur after 1998. Besides, iCalendar should work for dates before 1998; I'd want to use it that way myself. Why limit it to future dates? I suppose we could use long/lat coordinates :) That would work technically: e.g. instead of `/America/Los_Angeles' you would use `/+340308-1181434' (with ISO 6709 notation for latitude and longitude). I also considered that, but decided against it for a couple of reasons. First, it's unfriendly. Second, I was worried that people might argue about the coordinates (where _is_ the center of Los Angeles, exactly?). what defines a region, and how do people know what region they are in? Ideally, a region would be a maximal set of points all sharing the same time history. A time history would start when standard time was introduced, and would continue to the indefinite future. As time goes on, regions split and the number of regions grows. The Olson database deviates from this ideal by making two concessions to practicality. First, it looks only at time histories since 1970 when determining regions; this greatly reduces the number of regions (which would otherwise be in the thousands). Second, regions never cross current country boundaries; this is a concession to politics that I would have rather avoided from a theoretical point of view, but there were practical arguments for it (see below). Ideally, regions would appear on a map, and someone has actually done this for the Olson database; but I would urge that this not be made part of the standard, for political reasons as well as technical ones. Perhaps you could put the region boundaries into a non-normative annex or whatever the IETF calls that sort of thing. The most populous city within a region still would't suffice to define names for all of Indiana's timezone histories. Why not? There must be at least one location for each unique time history. Just pick the most populous one. Indiana has only 345 unique histories, according to Shanks (1990); each one has at least one town in it. I realize that there are places where /XX/city works better, (because everybody who is nearby stays in sync with that city's time) but there are also a lot of places in the states for which "Eastern" "Central" "Mountain" and "Pacific" are the obvious names. The obvious names don't work once you take into account the fact that cities can change time zones or time zone rules. This happened, for example, to Boise in 1974, to Anchorage in 1983, to Knox, IN in 1991, and to Cancun last year; we can be pretty sure that it will happen again soon to somebody. I wonder if the average J. Random Windows user, when asked to specify his timezone, really wants to name a city in another country, even if it is the largest city in his "region". This isn't a problem, since (as mentioned above) regions never cross current country boundaries in the Olson database. From Markus.Kuhn at cl.cam.ac.uk Sun Aug 9 08:32:47 1998 From: Markus.Kuhn at cl.cam.ac.uk (Markus Kuhn) Date: Sun, 09 Aug 1998 09:32:47 +0100 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Sat, 08 Aug 1998 15:52:30 PDT." <199808082252.PAA15334@shade.twinsun.com> Message-ID: Keith Moore wrote on 1998-08-08: > (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX > is the iso 3166 country code and yyy is a political subdivision > within that country. In many cases just /XX suffices. I have only seen this short excerpt from your mail quoted by Paul on the tz list, so I don't know whether you already know that there exists a new ISO 3166-2 draft standard, which defines ISO alpha codes for regional subdivisions within countries (e.g., the states in US and the bundesl?nder in DE): ISO 3166-1:1997, Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes ISO/DIS 3166-2, Codes for the representation of names of countries and their subdivisions -- Part 2: Country subdivision code ISO/DIS 3166-3, Codes for the representation of names of countries and their subdivisions -- Part 3: Code for formerly used names of countries Paul Eggert replied on 1998-08-08: > Why not just stick with the names already in the Olson database, > preceded by `/' if necessary for the new standard? The Olson names > are widely used existing practice, and I don't see a technical reason > to change them. I agree that naming a time zone after the most populated city within that time zone is a very flexible and sound approach. The only thing that irritates me about the Olson/Eggert tz names is that they are all prefixed by the continent name, which I feel is redundant information. Is there really a good rationale why it has to be "Europe/Berlin" for the German time zone and not just "Berlin". I know that the tz database is structured into several per-continent files, but if we propose these names as a more widely used standard, does the tz source file name really have to be a part of it? If there is not a very good rationale for the continent part of the names used in the tz database and if they are only an implementation kludge for allowing to split the database into several smaller files, then I suggest we consider dropping the continent names quickly (which can certainly be done in some backwards compatible manner). Apart form this detail, the tz database names are certainly the best scheme for naming time zones that I have seen so far and, like Paul, I am very skeptical about inventing a new one based on political boundaries. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: From Antoine.Leca at renault.fr Mon Aug 10 09:56:18 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Mon, 10 Aug 1998 11:56:18 +0200 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt References: Message-ID: <35CEC3C2.B80C955@renault.fr> Markus Kuhn wrote: > > Keith Moore wrote on 1998-08-08: > > (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX > > is the iso 3166 country code and yyy is a political subdivision > > within that country. In many cases just /XX suffices. > > I don't know whether you already know that there exists a > new ISO 3166-2 draft standard, which defines ISO alpha codes for > regional subdivisions within countries (e.g., the states in US and the > bundesl?nder in DE): As Paul explained, this might be inappropriate. For example, the finest degree for Indiana according to ISO DIS 3166-2 is US-IN, and this does not accord with current practice. OTOH, there is Europe or the Western Indies... take a look below! > I agree that naming a time zone after the most populated city within > that time zone is a very flexible and sound approach. The only thing > that irritates me about the Olson/Eggert tz names is that they are all > prefixed by the continent name, which I feel is redundant information. > Is there really a good rationale why it has to be "Europe/Berlin" for > the German time zone and not just "Berlin". First, I should say that I see no reason to invent a new scheme: better to not always reinvent the wheel! Well, my problem is that, *in the view of the iCalendar protocol*, adding a different entry for each country may be an unnecessary burden. So I think that the CET (or MEZ) timezone ought to be named "/Paris" (or "/Berlin", if Berlin is more populated than Paris), instead as the current count: Africa/Ceuta Arctic/Longyearbyen Europe/Amsterdam Europe/Andorra Europe/Belgrade Europe/Berlin Europe/Bratislava Europe/Brussels Europe/Budapest Europe/Copenhagen Europe/Gibraltar Europe/Ljubljana Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Monaco Europe/Oslo Europe/Paris Europe/Prague Europe/Rome Europe/San_Marino Europe/Sarajevo Europe/Skopje Europe/Stockholm Europe/Tirane Europe/Vaduz Europe/Vatican Europe/Vienna Europe/Warsaw (currently questionable) Europe/Zagreb Europe/Zurich to a grand total of 31 entries! Please note that Keith pointed out the number of aliases in the tz database. Paul's answer lead me to think he understood it as the concept of "Link" that is here for backward compatibility reasons. But links are easy to skip; this is not the same game when one has to identify "Europe/London" and "Europe/Lisbon", that have very different history as timezones, but that are now equal, and also equal in the foreseable future. I believe that we should try to keep a minimum number of timezones, at least to not have to worry small implementations, and to keep the requirements on network traffic as small as possible. Antoine From Antoine.Leca at renault.fr Mon Aug 10 09:28:21 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Mon, 10 Aug 1998 11:28:21 +0200 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt References: <199808090216.WAA17388@spot.cs.utk.edu> <199808090627.XAA15475@shade.twinsun.com> Message-ID: <35CEBD35.52828B7F@renault.fr> Keith wrote: > How important is it for iCalendar timezones to work before 1998? and Paul answered: > iCalendar should be able to handle the problems that occurred before > 1998, because it's likely that similar problems will occur after 1998. That is very true. In my eyes, that means that the naming scheme for timezones should be extensible. Right, Paul? > Besides, iCalendar should work for dates before 1998; I'd want to use > it that way myself. Why limit it to future dates? Well, that is another point. In my eyes, we should be able to use the mechanisms described in iCalendar for any use, including in the past (and I hope it successed on this way). OTOH, the aim here is to do a world-wide repository about timezones suitable for Internet scheduling, and here I believe the past problems will be an additional weight with no useful properties. Or should we have two repositories? As you pointed out, my goal is to do an automatic tool that "tranforms" the files at Olson database (tzdata19XXa.tar.gz, not the ones produced by zic) to a database in iCal format (and to Microsoft Win32's format as well). Therefore, be this database served by an Internel protocol, or be it used internaly with proprietary tools is IMHO a personal choice. Antoine From eggert at twinsun.com Mon Aug 10 22:03:14 1998 From: eggert at twinsun.com (Paul Eggert) Date: Mon, 10 Aug 1998 15:03:14 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <35CEBD35.52828B7F@renault.fr> (Antoine.Leca@renault.fr) References: <199808090216.WAA17388@spot.cs.utk.edu> <199808090627.XAA15475@shade.twinsun.com> <35CEBD35.52828B7F@renault.fr> Message-ID: <199808102203.PAA18454@shade.twinsun.com> Date: Mon, 10 Aug 1998 11:28:21 +0200 From: Antoine Leca the naming scheme for timezones should be extensible. Right, Paul? Yes. The number of time regions will increase with time. > Besides, iCalendar should work for dates before 1998; I'd want to use > it that way myself. Why limit it to future dates? the aim here is to do a world-wide repository about timezones suitable for Internet scheduling, and here I believe the past problems will be an additional weight with no useful properties. It might be reasonable for iCalendar to ignore transitions before, say, July 1998 when considering what regions to have in its world-wide repository. This would lower the number of regions considerably. But why bother? The existing tz data gets you back to 1970 for free. It should be slightly more work to start with July 1998 (because you'll have to coalesce regions, select canonical representatives, and so forth) than to start with January 1970 (which should be a simple data translation). Date: Mon, 10 Aug 1998 11:56:18 +0200 From: Antoine Leca "Europe/London" and "Europe/Lisbon", that have very different history as timezones, but that are now equal, and also equal in the foreseable future. That's not a good example, as Europe/London and Europe/Lisbon are currently distinct. Their TZNAMEs differ: Europe/London uses `GMT/BST', whereas Europe/Lisbon uses `WET/WEST'. (Also, when the liberals return to power in Portugal, they may well switch the clocks forward again. :-) However, I agree with your main point: the number of regions will decrease if we drop Europe/Berlin, Europe/Rome, etc. and standardize on Europe/Paris. Would this be acceptable politically, though? As Keith Moore pointed out, J. Random Windows user in, say, Berlin might be a bit upset if he has to point his browser at Paris to set his time zone. I believe that we should try to keep a minimum number of timezones, at least to not have to worry small implementations, and to keep the requirements on network traffic as small as possible. Can you estimate how much would be saved by going with a 1998 horizon versus a 1970 horizon? I don't think it would be all that much, but I don't know what the assumptions are. From olsona at dc37a.nci.nih.gov Tue Aug 11 03:28:35 1998 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NCI)) Date: Mon, 10 Aug 1998 23:28:35 -0400 Subject: tzdata1998g.tar.gz Message-ID: <43E124CC389ED111B18D00805FEA1E63BC4BB2@nihexchange2.nih.gov> The file ftp://elsie.nci.nih.gov/pub/tzdata1998g.tar.gz is now available; it incorporates the Lithuanian change provided by mgedmin at pub.osf.it; it also moves creation of the GMT link with Etc/GMT to "etcetera" (from "backward") to ensure that the GMT file is created even where folks don't want the "backward" links (as suggested by Paul Eggert). --ado From eggert at twinsun.com Tue Aug 11 05:58:30 1998 From: eggert at twinsun.com (Paul Eggert) Date: Mon, 10 Aug 1998 22:58:30 -0700 Subject: pending changes to tz database, mostly from the IATA In-Reply-To: <43E124CC389ED111B18D00805FEA1E63BC4BB2@nihexchange2.nih.gov> (olsona@dc37a.nci.nih.gov) References: <43E124CC389ED111B18D00805FEA1E63BC4BB2@nihexchange2.nih.gov> Message-ID: <199808110558.WAA20753@shade.twinsun.com> I am about to send out changes to the time zone database compiled mostly from data kindly abstracted from the IATA tables by Gwillim Law. Here is a verbal description. Please let me know if any of these changes seem bogus; otherwise, I'll send out a proposed patch shortly. * Quintana Roo switched from CST/CDT to EST/EDT; we assume this happened last fall. This requires a new entry, America/Cancun. * Chihuahua switched from CST/CDT to MST/MDT; we assume this happened this spring. This requires a new entry, America/Chihuahua. * Cuba has changed the rules again. The 1998 change dates are Mar 29 and Oct 25. Thereafter, the rules will be the same as the US, except that the time of switch is 00:00 instead of 02:00. * Haiti stopped observing DST this year. * Starting in 1999, Paraguay switches the last Sunday in February, not March 1. * Starting this year, Estonia uses the EU rules; i.e. it switches at 01:00 UTC (03:00 standard time), not 02:00 standard time. * tzdata1998g.tar.gz has a glitch: it moves the Lithuanian clocks back by an hour at 1998 Mar 29 02:00, waits an hour, and then moves them forward an hour when 02:00 comes by again. Also, the new rules are identical to EU. * Crimea switched from Moscow time back to EET/EEST; we assume it happened in March 1997. * Starting this year, Armenia observes DST again, using the same rules as Russia. * Starting last year, Azerbaijan observes DST, using rules like Russia's except with transition times at 01:00 instead of 02:00. * Starting last year, Kirgizstan adopted DST rules like Russia's, except with transition times at 02:30 instead of 02:00. * Last fall Libya converted from CET/CEST to EET with no DST. Its spring 1997 transition was April 4 at 00:00, not Mar 27 at 02:00. * Egypt's DST rules are the fourth Friday in April at 00:00 to the last Friday in September at 24:00. The current tz database has the rules as the last Friday in April at 01:00 to the last Friday in September at 03:00, due to my transcription errors the last time around. * New Caledonia stopped observing DST in 1997; it was just a 1-year experiment. * The Cook Islands stopped observing DST in 1991. (This claim is from the 1995 edition of Shanks, not from the IATA.) * For the capital of Kazakhstan, the name `Almaty' now has a 2-to-1 majority over the old Russian-derived name `Alma-Ata' in English-language prose, as measured by Alta Vista; so it's time to switch the name in the database, with a backward-compatibility link. From okellyd at logica.com Wed Aug 12 22:12:15 1998 From: okellyd at logica.com (O'Kelly, David) Date: Wed, 12 Aug 1998 18:12:15 -0400 Subject: Lat. / Long to timezone conversion Message-ID: To whom it may concern, I am currently trying to identify if there are any existing software products which can carry out a Latitude / Longitude conversion to the corresponding timezone. Initially I am concentrating on data for the U.S., Canada & Mexico and was wondering if any relevant or pertinent information may be available on this subject. Thank you for any help you can provide. - regards Dave David O'Kelly Principal Software Engineer Communications Division Logica Inc. tel + 1 415 288 5200 fax + 1 415 288 5299 email okellyd at logica.com From rthelen at netapp.com Fri Aug 21 23:16:37 1998 From: rthelen at netapp.com (Randy Thelen) Date: Fri, 21 Aug 1998 16:16:37 -0700 Subject: Possible Bug in INT_STRLEN_MAXIMUM macro Message-ID: <35DDFFD5.B1F1D688@netapp.com> The INT_STRLEN_MAXIMUM macro in lib/private.h used by, among other files, asctime.c, states in its comment field: /* ** 302 / 1000 is log10(2.0) rounded up. ... */ And then in the macro definition we find: #define INT_STRLEN_MAXIMUM(type) \ ... * 302 / 100 ... Me thinks this is not what was intended. Possibly it's an error, possibly it's the right thing. Could you send mail back telling me if this was on purpose? -- Randy Thelen Software Engineer Network Appliance, Inc. From Markus.Kuhn at cl.cam.ac.uk Sat Aug 22 20:51:38 1998 From: Markus.Kuhn at cl.cam.ac.uk (Markus Kuhn) Date: Sat, 22 Aug 1998 21:51:38 +0100 Subject: Revision of ISO C 9x Message-ID: The new ISO C draft is on . I think, the following message might be of interest to many here: ------- Forwarded Message Date: Sat, 22 Aug 1998 21:00:08 +0100 To: David R Tribble , Antoine.Leca at renault.fr, kuhn at cs.purdue.edu From: "Clive D.W. Feather" Reply-To: "Clive D.W. Feather" Subject: It's about time [sorry for the bad joke] I'm sorry I've taken so long to get back to people about this. This email is going to all the people who have expressed to me an interest in the C9X time functions. C9X CD2 (aka the FCD) is now published (it can be found on the DKUUG web site). It basically contains the same material in as CD1 did, though a few minor errors have been corrected and Keld's %O and %E modifiers have appeared. Everyone who's written to me has expressed dissatisfaction with some part or other of the current situation. Therefore I have a rather radical proposal to make: I suggest we write a complete new section that addresses all our issues, and arrange for at least two, and preferably three or more, National Bodies to submit it as part of their response to CD2. I'm willing to act as the core editor for this work, provided: - - people will write full pieces of text for me to drop in as needed; - - people won't object to my use of editorial powers to tidy up and keep the wording consistent. I can provide web space where I will keep the working drafts. I suggest we start with what's in CD2 as a common base, though being ready to drop pieces if that's what we agree. In the meantime, here's all the issues that I'm aware of that our text would need to handle: (1) Clear definition of canonicalisation of times. (2) Unambigous mechanisms for converting between UTC and TAI, and between time zones, and for determining which is in use. (3) Clearer definitions of things like strftime conversions (all of these are in CD2, so this is a no-op). (4) Ability to determine the precision of times (a ticks per second macro, perhaps). This should be guaranteed to be <= 1 second over some range. (5) Ability to determine the range of time_t, with guaranteed minimum limits. (6) A member in struct tmx for access to subsecond resolution, and possibly new formats to access it. (7) The meaning of struct tm to remain source and binary compatible with C89. (8) Clearer definition of what struct tm[x] values must be handled by implementations. (9) All new functions to be re-entrant. (10) Rethink future expandibility of struct tmx. (11) Portable form for transferring time values between programs and implementations. Anything else ? I've no objection to this message having wider circulation, but only to people who aren't going to require more education than there's time for. - -- Clive D.W. Feather | Regulation Officer, LINX | Work: Tel: +44 1733 705000 | (on secondment from | Home: Fax: +44 1733 353929 | Demon Internet) | Written on my laptop; please observe the Reply-To address ------- End of Forwarded Message From olsona at dc37a.nci.nih.gov Mon Aug 24 13:17:34 1998 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NCI)) Date: Mon, 24 Aug 1998 09:17:34 -0400 Subject: Possible Bug in INT_STRLEN_MAXIMUM macro Message-ID: <43E124CC389ED111B18D00805FEA1E63BC4BBC@nihexchange2.nih.gov> -----Original Message----- From: Randy Thelen [SMTP:rthelen at netapp.com] Sent: Friday, August 21, 1998 7:17 PM To: tz at elsie.nci.nih.gov Cc: guy at netapp.com Subject: Possible Bug in INT_STRLEN_MAXIMUM macro The INT_STRLEN_MAXIMUM macro in lib/private.h used by, among other files, asctime.c, states in its comment field: /* ** 302 / 1000 is log10(2.0) rounded up. ... */ And then in the macro definition we find: #define INT_STRLEN_MAXIMUM(type) \ ... * 302 / 100 ... Me thinks this is not what was intended. Possibly it's an error, possibly it's the right thing. Could you send mail back telling me if this was on purpose? -- Randy Thelen Software Engineer Network Appliance, Inc. The bad news is that the macro definition indeed fails to match the comment; the good news is that the error results in over-generous sizing of arrays designed to hold ASCII representations of numbers. I've changed the "100" in the "#define" to the correct "1000"; the change will show up in the next version of tzcode. --ado From MPaul5045 at aol.com Mon Aug 3 17:57:19 1998 From: MPaul5045 at aol.com (MPaul5045 at aol.com) Date: Mon, 3 Aug 1998 13:57:19 EDT Subject: Graphic and Cartoon Competition Message-ID: <7795fbbb.35c5fa01@aol.com> Graphic and Cartoon Competition Concours de l'art graphique et de la caricature Grafik- und Karikaturenwettbewerb http://www.zibb.de Grafik- und Karikaturenwettbewerb der Zahntechniker-Innung Berlin-Brandenburg zum Thema "F?r Z?hne gibt es keine Alternative. Aber Ersatz!" Unter dem Motto "Wer gesunde und sch?ne Z?hne hat, f?hlt sich wohl und lacht gern" veranstalteten wir 1996/97 einen gro?en Foto- und Ideenwettbewerb. Weit ?ber 1000 Teilnehmer reichten hierzu ihre Beitr?ge ein. Die Besten wurden pr?miert und sind im Internet (http://www.zibb.de ) unter der Rubrik "Foto- und Ideenwettbewerb" dokumentiert. Mit unserem neuen Grafik- und Karikaturenwettbewerb wollen wir an diese erfolgreiche Aktion ankn?pfen. Machen Sie mit! Teilnahmebedingungen ? Gesucht werden zum Wettbewerbsthema selbst gestaltete Grafiken und Karikaturen. ? Wettbewerbsbeitr?ge k?nnen eingereicht werden in der Zeit vom 1. April bis 30. November 1998. Sie sind zu richten an die: Zahntechniker-Innung Berlin-Brandenburg Alt-Moabit 105, 10559 Berlin. ? Im Wettbewerbszeitraum eingereichte themengerechte Beitr?ge werden in einer monatlichen "Hitliste" im Internet ver?ffentlicht. ? Eine unabh?ngige Jury w?hlt aus den im Internet ver?ffentlichten Beitr?gen im Januar 1999 die besten Arbeiten zur Pr?mierung aus. Die Pr?mierung erfolgt im Februar 1999. ? Die zw?lf besten Beitr?ge werden pr?miert mit: 1. Preis 3.000,00 DM 2. Preis 2.000,00 DM 3. Preis 1.000,00 DM 4.-12. Preis 500,00 DM ? Die Preistr?ger und ihre Beitr?ge werden von Februar bis Dezember 1999 im Internet ver?ffentlicht. ? Die zw?lf pr?mierten Beitr?ge werden voraussichtlich in einem repr?sentativen Wandkalender ver?ffentlicht. ? S?mtliche eingesandten Beitr?ge k?nnen f?r Werbeartikel, wie Brosch?ren und Plakate durch die Zahntechniker-Innung Berlin-Brandenburg genutzt werden. Teilnehmen kann jede Person mit beliebig vielen Beitr?gen. Mit der Einsendung seines Wettbewerbsbeitrags erkl?rt der Teilnehmer sein Einverst?ndnis mit den Teilnahmebedingungen. Die Arbeiten sollten in der Regel im Format DIN A4 (210 x 297 mm) sein, jedoch nicht gr??er als DIN A3 (297 x 420 mm). S?mtliche Beitr?ge m?ssen gut leserlich mit Namen, Adresse, Beruf und Altersangabe versehen sein. Zahntechniker-Innung Berlin-Brandenburg Graphic and Cartoon Competition of the Zahntechniker-Innung Berlin-Brandenburg on the topic "For teeth there is no alternative. But denture!" In 1996/97 we launched a big photo and idea competition. The motto was: "With healthy and beautiful teeth you feel good and like laughing". More than 1000 participants sent in their contributions. The best of them got prizes and can be found in the internet (http://www.zibb.de) under the heading "Foto- und Ideenwettbewerb". We want to continue this successful campaign with our new Graphic and Cartoon Competition. Join the contest! Conditions of participation ? We are looking for illustrations and cartoons, created by the participants, on the subject of the competition. ? Contributions can be sent in from1st April to 30th November 1998. The address is: Zahntechniker-Innung Berlin-Brandenburg (Dental Technicians Corporation Berlin- Brandenburg) Alt-Moabit 105, 10559 Berlin Germany ? All contributions coming in until the deadline will be published in our monthly "Top 10 ..." in the Internet ? An independent jury will chose the best works out of those published in the internet in January 1999. The prizes will be awarded in February 1999. ? Twelve winning contributions will be awarded with: ? 1st prize 3.000,00 DM 2nd prize 2.000,00 DM 3rd prize 1.000,00 DM 4th to 12th prize 500,00 DM ? The winners and their works will be published in the Internet from February to December 1999. ? The twelve wining contributions will probably be published in a representative calendar. ? All contributions can be used for advertising, i.e. for brochures and posters by the Zahntechniker-Innung Berlin-Brandenburg. Anyone can participate with an optional number of pieces of work. By sending in his/her contribution the participant agrees with the conditions of participation. The works should have the regular format DIN A4 (210 x 297 mm) but they should not exceed format DIN A3 (297 X 420 mm). Name, address, occupation and age of the participant are supposed to be on the piece in a readable condition. Concours de l'art graphique et de la caricature organise par la chambre des Zahntechniker-Innung Berlin-Brandenburg sur le sujet ""Il n' y a pas d'alternative aux dents, que des substituts!" En 1996/97 nous avons organis? un grand concours cr?atif et photographique sur le sujet "Celui qui a des dents saines et belles se sent bien et aime rire". Il y avait plus de 1000 participants. Les meilleurs r?sultats ont accord? un prix et ils ont ?t? publi?s sur l'Internet ( http://www.zibb.de) sous la rubrique de "Concours cr?atif et photographique". ? cause du succ?s de cette action nous voulons continuer avec notre nouveau concours graphique et de la caricature. Participez-y! Bonne chance! Conditions de participation ? Nous cherchons des graphiques et caricatures cr?es au sujet du concours. ? La date limite des envois est le 30 novembre 1998. Adressez vos graphiques et caricatures ?: Zahntechniker-Innung Berlin-Brandenburg (Chambre des parodontistes Berlin-Brandenburg) Alt-Moabit 105, 10559 Berlin. Allemagne ? Pendant la p?riode du concours on va publier sur l'Internet les favorites mensuelles. ? En janvier 1999 un jury ind?pendant va choisir les meilleurs r?sultats de toutes les publications sur l'Internet. L'attribution des prix aura lieu en f?vrier 1999. ? Les douze meilleurs participants primeront: ? 1. prix 3.000,00 DM 2. prix 2.000,00 DM 3. prix 1.000,00 DM 4.-12. prix 500,00 DM ? Du f?vrier au d?cembre 1999 les laur?ats et leurs cr?ations seront publi?s ? l'Internet et de surcro?t ? un calendrier mural repr?sentatif. ? Toutes les graphiques et caricatures peuvent ?tre utilis?s aux articles de publicit? comme brochures et affiches par la chambre des m?canicien-dentistes Berlin-Brandenburg. Chacun peut y participer avec un nombre illimit? de propositions. Par l'envoi des cr?ations chaque participant d?clare son accord aux conditions de la participation. Le format des travaux devrait ?tre ? pr?f?rence DIN A 4 (210 sur 297 mm) et pas d?passer le format DIN A 3 (297 sur 420 mm). Indiquez s.v.p. toujours votre nom, l'adresse, la profession et l'?ge. (Chambre des parodontistes Berlin-Brandenburg) Zahntechniker-Innung Berlin-Brandenburg -------------- next part -------------- A non-text attachment was scrubbed... Name: WETTFILM.JPG Type: image/jpeg Size: 30437 bytes Desc: not available URL: From Antoine.Leca at renault.fr Wed Aug 5 09:46:04 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Wed, 05 Aug 1998 11:46:04 +0200 Subject: time_t (2000 problem) References: <199808050857.JAA07856@rattle.soton.sc.philips.com> Message-ID: <35C829DC.6B9EF989@renault.fr> Hi, Stephen Baynes wrote: > > > That is a thing I am interested in investigating. > > Are you interested to work in this area (I search after volunteers!) > > > > I would be interested if I had the time. OK. I forgot to point you to the elsie mailing list. In any case, if work is effectively begining, it will take place closely to this group. Do you know it? If not, you might consider subscribing (mail at tz-request at elsie.nci.nih.gov, IIRC). Antoine From stephen.baynes at soton.sc.philips.com Wed Aug 5 10:07:33 1998 From: stephen.baynes at soton.sc.philips.com (Stephen Baynes) Date: Wed, 5 Aug 1998 11:07:33 +0100 Subject: time_t (2000 problem) Message-ID: <199808051007.LAA13346@rattle.soton.sc.philips.com> Antoine.Leca wrote: > > I forgot to point you to the elsie mailing list. > In any case, if work is effectively begining, it will take place > closely to this group. > Do you know it? > I have not heard of it. What is it about? I assume something about time, but is it very specific or very general? Also how much trafic does it carry? > If not, you might consider subscribing (mail at > tz-request at elsie.nci.nih.gov, IIRC). > If it is of interest and does not carry too much trafic, then I will subscribe. Stephen From guy at netapp.com Wed Aug 5 17:58:10 1998 From: guy at netapp.com (Guy Harris) Date: Wed, 5 Aug 1998 10:58:10 -0700 (PDT) Subject: time_t (2000 problem) In-Reply-To: <35C829DC.6B9EF989@renault.fr> from Antoine Leca at "Aug 5, 98 11:46:04 am" Message-ID: <199808051758.KAA25137@tooting.netapp.com> > > > That is a thing I am interested in investigating. What is the thing in question? From moore at cs.utk.edu Thu Aug 6 00:57:06 1998 From: moore at cs.utk.edu (Keith Moore) Date: Wed, 05 Aug 1998 20:57:06 -0400 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Thu, 16 Jul 1998 17:43:53 PDT." <199807170043.RAA11414@shade.twinsun.com> Message-ID: <199808060057.UAA06831@spot.cs.utk.edu> > * A more consistent naming strategy for TZIDs. The current draft is > inconsistent: for the same time zone it sometimes says > "America-New_York", sometimes "America-New York", and sometimes > other things like "Eastern". TZIDs are arbitrary, but a good naming > convention can help reduce the number of errors, ease maintenance, > and improve interoperability. What I'd really like to see is a separate document defining globally-scoped timezone names. That way, TZIDs don't have to be arbitrary. I would think that such a document would want to use a subset of the names in the Olsen database. e.g. "/US/Eastern" > * A reference to the Olson database prior art. Many potential > implementers don't know about this useful source, and have thereby > propagated incorrect time zone data. I agree that this would be useful. > * Allow UTC offsets that are not multiples of one minute. This is > needed for historically recent applications (e.g. the time zone in > Liberia up to 1972). > > * The examples should be a tad more careful about distinguishing > between US Eastern time and New York time, since there was a lot of > confusion about the Eastern time zone before, say, 1976. These also seem appropriate. Keith From Antoine.Leca at renault.fr Thu Aug 6 09:33:44 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Thu, 06 Aug 1998 11:33:44 +0200 Subject: time_t (2000 problem) References: <199808051758.KAA25137@tooting.netapp.com> Message-ID: <35C97878.AD43B662@renault.fr> Guy Harris wrote: > > > > > That is a thing I am interested in investigating. > > What is the thing in question? I am sorry to all you guys at tz list. I did a mistake when privately discussing with Stephen. All right, some more explanations: we had discussions in both news:comp.std.c and the C committee (WG14) about extensions to the Standard C library about time. I am searching people interested to further investigate this area, and I proposed it to Stephen. To improve its knowledge, I give him the address of tz list, which I find is among the most relevant source in this area. But I did it wrong, and I copied the list; hence you received the previous message about it. So, sorry again for annoying everybody here. Best regards, Antoine From mgedmin at pub.osf.lt Fri Aug 7 22:01:36 1998 From: mgedmin at pub.osf.lt (Marius Gedminas) Date: Sat, 8 Aug 1998 00:01:36 +0200 Subject: Time zone update Message-ID: <19980808000136.C651@mg.home> I would like to inform that in this year Lithuanian time zone (Europe/Vilnius) was changed. Here's a diff: -------------- next part -------------- --- europe.orig Thu Sep 4 23:54:16 1997 +++ europe Fri Aug 7 14:05:03 1998 @@ -1526,7 +1526,8 @@ 1:00 C-Eur CE%sT 1944 Aug 3:00 Russia MSK/MSD 1991 Mar 31 2:00s 2:00 1:00 EEST 1991 Sep 29 2:00s - 2:00 C-Eur EE%sT + 2:00 C-Eur EE%sT 1998 Mar 29 2:00s + 1:00 C-Eur CE%sT # From Paul Eggert (1996-11-22): # IATA SSIM (1992/1996) says Lithuania uses W-Eur rules, but since it is # known to be wrong about Estonia and Latvia, assume it's wrong here too. -------------- next part -------------- Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin at pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86 From poleary at amplitude.com Sat Aug 8 21:10:23 1998 From: poleary at amplitude.com (Pete O'Leary) Date: Sat, 8 Aug 1998 14:10:23 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <199808060057.UAA06831@spot.cs.utk.edu> Message-ID: <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> Keith, I assume you mean globally-scoped names together with their corresponding VTIMEZONE component? I think this is a really good idea as well, but it's a fairly signifigant undertaking. There is alot of information in the Olson work than needs to be converted into iCalendar VTIMEZONE format. From the looks of it, this could be done semi-automatically. Any takers? I could be impelled into leading this effort, but I think we'll need to discuss the scope of this in Chicago. Pete. > -----Original Message----- > > * A more consistent naming strategy for TZIDs. The current draft is > > inconsistent: for the same time zone it sometimes says > > "America-New_York", sometimes "America-New York", and sometimes > > other things like "Eastern". TZIDs are arbitrary, but a good naming > > convention can help reduce the number of errors, ease maintenance, > > and improve interoperability. > > What I'd really like to see is a separate document defining > globally-scoped timezone names. That way, TZIDs don't have to be > arbitrary. I would think that such a document would want to use a > subset of the names in the Olsen database. e.g. "/US/Eastern" From moore at cs.utk.edu Sat Aug 8 21:49:54 1998 From: moore at cs.utk.edu (Keith Moore) Date: Sat, 08 Aug 1998 17:49:54 -0400 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Sat, 08 Aug 1998 14:10:23 PDT." <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> Message-ID: <199808082149.RAA16636@spot.cs.utk.edu> > I assume you mean globally-scoped names together with their corresponding > VTIMEZONE component? Yes, that's what I had in mind. But just defining the format of the global timezone names themselves would be a useful first step. (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices. This probably doesn't cover all timezones that one might want to define, but it's a start.) -Keith From eggert at twinsun.com Sat Aug 8 22:52:30 1998 From: eggert at twinsun.com (Paul Eggert) Date: Sat, 8 Aug 1998 15:52:30 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <199808082149.RAA16636@spot.cs.utk.edu> (moore@cs.utk.edu) References: <199808082149.RAA16636@spot.cs.utk.edu> Message-ID: <199808082252.PAA15334@shade.twinsun.com> From: Keith Moore Date: Sat, 08 Aug 1998 17:49:54 -0400 (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices. Why not just stick with the names already in the Olson database, preceded by `/' if necessary for the new standard? The Olson names are widely used existing practice, and I don't see a technical reason to change them. If the ``don't mess with success'' argument is not enough to convince you, then let me explain why the Olson names are the way they are; perhaps that will help. I originally tried using an /XX/yyy style naming convention when I was designing the naming scheme currently used by the Olson database, but I discovered several problems with /XXX/yyy: * Time zone rule boundaries are not well correlated with current political subdivisions. For example, it is tempting to use `/US/IN' for US Eastern Standard Time without DST, as is currently practiced in most of Indiana, but that is incorrect, since part of Indiana _does_ observe DST. * Indiana alone has hundreds of distinct time zone histories, only a few of which are in the Olson database due to its 1970 cutoff; as time goes on, more will need to be added to the Olson database. Even if we identified which subdivisions of Indiana would work for today's time zone histories (which would be a lot of work), the divisions would need to be further subdivided in the future, and this will cause compatibility problems. * The names and boundaries of political subdivisions change too often. Even if we were to come up with names that work today, they would soon become obsolete. It's more stable to choose names that depend as little as possible on politics. * Using political subdivisions injects politics into what should be a technical discussion. To some extent this is unavoidable, but it should be forestalled as much as possible by avoiding political subdivisions in the first place. For these reasons, I used a naming convention that does not try to identify the political boundaries of a time zone rule region. Instead, I used the name of the most populous single location within the region. This method is be less controversial, more stable, and more accurate than trying to name the entire region. This naming regime survived the demise of the Soviet Union without having to rename `Europe/Moscow' or `Asia/Tashkent'; it survived the recent revolution in the Congo without having to worry about its country-code change; and it survived the conflict between India and Pakistan in Kashmir without having to suffer an embargo (unlike Microsoft Windows, which unwisely put political boundaries into its database). It's not infallible; e.g. when Kuybyshev (the most populous city in Russian UTC+4) changed its name back to Samara, the database had to change its name too. But in practice the current Olson scheme has turned out to be more stable than any scheme based on political subdivisions. From eggert at twinsun.com Sat Aug 8 22:57:26 1998 From: eggert at twinsun.com (Paul Eggert) Date: Sat, 8 Aug 1998 15:57:26 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> (poleary@amplitude.com) References: <006101bdc310$f4db55b0$0778dad0@neworleans.amplitude.com> Message-ID: <199808082257.PAA15348@shade.twinsun.com> From: "Pete O'Leary" Date: Sat, 8 Aug 1998 14:10:23 -0700 There is alot of information in the Olson work than needs to be converted into iCalendar VTIMEZONE format. From the looks of it, this could be done semi-automatically. Any takers? On July 16 Antoine Leca wrote that he is doing exactly that, though my impression was that he is doing it automatically, not semiautomatically. You might contact him to see what his current status is. It should be a simple matter of hacking the existing zic parser. From moore at cs.utk.edu Sun Aug 9 02:16:01 1998 From: moore at cs.utk.edu (Keith Moore) Date: Sat, 08 Aug 1998 22:16:01 -0400 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Sat, 08 Aug 1998 15:52:30 PDT." <199808082252.PAA15334@shade.twinsun.com> Message-ID: <199808090216.WAA17388@spot.cs.utk.edu> > From: Keith Moore > Date: Sat, 08 Aug 1998 17:49:54 -0400 > > (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX > is the iso 3166 country code and yyy is a political subdivision > within that country. In many cases just /XX suffices. > > Why not just stick with the names already in the Olson database, > preceded by `/' if necessary for the new standard? The Olson names > are widely used existing practice, and I don't see a technical reason > to change them. Actually, when I suggested that '/' be the introducer for global timezones, I had the Olsen database in mind, and have always assumed that we should start with a subset of that database. But if you're trying to define a standard for global timezone names, it makes sense to think carefully about them and see if you want to keep all of the Olsen timezone names. Some of them don't seem authoritative enough. The Olson database has the (to me) undesirable property that there are a lot of aliases. It seems like we would rather have "canonical" names when possible. And the Olsen database tries to define names for everything. It might be better to not define timezone names where we don't have really good solid authoritative information, or where the local model of calendar doesn't quite fit with what iCalendar does. (like places that use solar time) > I originally tried using an /XX/yyy style naming convention when I was > designing the naming scheme currently used by the Olson database, but > I discovered several problems with /XXX/yyy: > > * Time zone rule boundaries are not well correlated with current > political subdivisions. For example, it is tempting to use `/US/IN' > for US Eastern Standard Time without DST, as is currently practiced > in most of Indiana, but that is incorrect, since part of Indiana > _does_ observe DST. I believe Indiana actually has three different time zones: EST year round EST/EDT (near Cincinnati, OH) CST/CDT (near Louisville, KY) and this varies, as I understand, on a county-by-county basis. (somewhere I have a map of Indiana with different counties shaded according to their timezones) So you clearly can't force everything into clean and easily rememberd political subdivisions - you have to deviate somewhere. I still think it's convenient if *most* of the timezones are easily remembered. (I don't see a problem with the different parts of Indiana using /US/Eastern, /US/Central, and /US/IN/no-dst, as appropriate) > * Indiana alone has hundreds of distinct time zone histories, only a > few of which are in the Olson database due to its 1970 cutoff; as > time goes on, more will need to be added to the Olson database. > Even if we identified which subdivisions of Indiana would work for > today's time zone histories (which would be a lot of work), the > divisions would need to be further subdivided in the future, and > this will cause compatibility problems. How important is it for iCalendar timezones to work before 1998? > * The names and boundaries of political subdivisions change too often. > Even if we were to come up with names that work today, they would > soon become obsolete. It's more stable to choose names that depend > as little as possible on politics. > > * Using political subdivisions injects politics into what should be a > technical discussion. To some extent this is unavoidable, but it > should be forestalled as much as possible by avoiding political > subdivisions in the first place. Well, I suppose we could use long/lat coordinates :) > For these reasons, I used a naming convention that does not try to > identify the political boundaries of a time zone rule region. > Instead, I used the name of the most populous single location within > the region. This method is be less controversial, more stable, and > more accurate than trying to name the entire region. Yes, but what defines a region, and how do people know what region they are in? (or for that matter, how do people know the most populous city in a region?) What timezone should I (in Knoxville, TN) use? Should I say /America/Cincinnati or /America/Atlanta or what? The most populous city within a region still would't suffice to define names for all of Indiana's timezone histories. I realize that there are places where /XX/city works better, (because everybody who is nearby stays in sync with that city's time) but there are also a lot of places in the states for which "Eastern" "Central" "Mountain" and "Pacific" are the obvious names. > This naming regime survived the demise of the Soviet Union without > having to rename `Europe/Moscow' or `Asia/Tashkent'; it survived the > recent revolution in the Congo without having to worry about its > country-code change; and it survived the conflict between India and > Pakistan in Kashmir without having to suffer an embargo (unlike > Microsoft Windows, which unwisely put political boundaries into its > database). It's not infallible; e.g. when Kuybyshev (the most > populous city in Russian UTC+4) changed its name back to Samara, the > database had to change its name too. But in practice the current > Olson scheme has turned out to be more stable than any scheme based on > political subdivisions. No argument there, and yet it would be nice if the names were obvious and guessable. It also seems like whenever there is a political border, we *know* there is a timezone fault-line where if a timezone changes on one side it will change independently of whatever is on the other side. There are of course other fault-lines: borders change, new borders are created, etc., but we can't anticipate everything. Finally, I wonder if the average J. Random Windows user, when asked to specify his timezone, really wants to name a city in another country, even if it is the largest city in his "region". (Note that the Pakistan/India conflict wouldn't have caused a problem anyway, because there was not a dispute about the names of the regions - only the borders of those regions.) Anyway, as I said earlier, I would defer to those with more experience. Keith From eggert at twinsun.com Sun Aug 9 06:27:53 1998 From: eggert at twinsun.com (Paul Eggert) Date: Sat, 8 Aug 1998 23:27:53 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <199808090216.WAA17388@spot.cs.utk.edu> (moore@cs.utk.edu) References: <199808090216.WAA17388@spot.cs.utk.edu> Message-ID: <199808090627.XAA15475@shade.twinsun.com> From: Keith Moore Date: Sat, 08 Aug 1998 22:16:01 -0400 The Olson database has the (to me) undesirable property that there are a lot of aliases. Those aliases are mostly the result of the transition of old-style Olson names (e.g. US/Pacific) to the new-style names (e.g. America/Los_Angeles). Any new standard could omit the old-style names; this would alleviate the problem of aliases. Some of those old names are popular, though.... It might be better to not define timezone names where we don't have really good solid authoritative information, or where the local model of calendar doesn't quite fit with what iCalendar does. If we insist on ``really good solid authoritative information'', then I'm afraid coverage will be limited. Nobody keeps track of this stuff authoritatively on a world-wide basis. Nobody even keeps track of it authoritatively for Indiana! People have called for official bodies to keep track of this stuff authoritatively -- the ISO, or the UN, or the IATA, or somebody. It hasn't happened, and I don't think it likely to happen soon. (like places that use solar time) Nobody uses solar time any more for civil time. The last holdout was Saudi Arabia; they converted to UTC+3 in 1950. I believe Indiana actually has three different time zones: EST year round EST/EDT (near Cincinnati, OH) CST/CDT (near Louisville, KY) and this varies, as I understand, on a county-by-county basis. It's worse than that: the rules were not always uniform within the same county. (I don't see a problem with the different parts of Indiana using /US/Eastern, /US/Central, and /US/IN/no-dst, as appropriate) That doesn't work, because it mishandles time stamps before and after transitions. For example, Starke County, Indiana, switched from CST/CDT to EST on 1991-10-27 (according to the Washington Post that day). So Starke County needs its own unique time zone history. You can't just say that Starke County is EST, because that would mishandle time stamps before the switch; and you can't just say that Starke County is CST/CDT, as that would mishandle timestamps after the switch. How important is it for iCalendar timezones to work before 1998? iCalendar should be able to handle the problems that occurred before 1998, because it's likely that similar problems will occur after 1998. Besides, iCalendar should work for dates before 1998; I'd want to use it that way myself. Why limit it to future dates? I suppose we could use long/lat coordinates :) That would work technically: e.g. instead of `/America/Los_Angeles' you would use `/+340308-1181434' (with ISO 6709 notation for latitude and longitude). I also considered that, but decided against it for a couple of reasons. First, it's unfriendly. Second, I was worried that people might argue about the coordinates (where _is_ the center of Los Angeles, exactly?). what defines a region, and how do people know what region they are in? Ideally, a region would be a maximal set of points all sharing the same time history. A time history would start when standard time was introduced, and would continue to the indefinite future. As time goes on, regions split and the number of regions grows. The Olson database deviates from this ideal by making two concessions to practicality. First, it looks only at time histories since 1970 when determining regions; this greatly reduces the number of regions (which would otherwise be in the thousands). Second, regions never cross current country boundaries; this is a concession to politics that I would have rather avoided from a theoretical point of view, but there were practical arguments for it (see below). Ideally, regions would appear on a map, and someone has actually done this for the Olson database; but I would urge that this not be made part of the standard, for political reasons as well as technical ones. Perhaps you could put the region boundaries into a non-normative annex or whatever the IETF calls that sort of thing. The most populous city within a region still would't suffice to define names for all of Indiana's timezone histories. Why not? There must be at least one location for each unique time history. Just pick the most populous one. Indiana has only 345 unique histories, according to Shanks (1990); each one has at least one town in it. I realize that there are places where /XX/city works better, (because everybody who is nearby stays in sync with that city's time) but there are also a lot of places in the states for which "Eastern" "Central" "Mountain" and "Pacific" are the obvious names. The obvious names don't work once you take into account the fact that cities can change time zones or time zone rules. This happened, for example, to Boise in 1974, to Anchorage in 1983, to Knox, IN in 1991, and to Cancun last year; we can be pretty sure that it will happen again soon to somebody. I wonder if the average J. Random Windows user, when asked to specify his timezone, really wants to name a city in another country, even if it is the largest city in his "region". This isn't a problem, since (as mentioned above) regions never cross current country boundaries in the Olson database. From Markus.Kuhn at cl.cam.ac.uk Sun Aug 9 08:32:47 1998 From: Markus.Kuhn at cl.cam.ac.uk (Markus Kuhn) Date: Sun, 09 Aug 1998 09:32:47 +0100 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: Your message of "Sat, 08 Aug 1998 15:52:30 PDT." <199808082252.PAA15334@shade.twinsun.com> Message-ID: Keith Moore wrote on 1998-08-08: > (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX > is the iso 3166 country code and yyy is a political subdivision > within that country. In many cases just /XX suffices. I have only seen this short excerpt from your mail quoted by Paul on the tz list, so I don't know whether you already know that there exists a new ISO 3166-2 draft standard, which defines ISO alpha codes for regional subdivisions within countries (e.g., the states in US and the bundesl?nder in DE): ISO 3166-1:1997, Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes ISO/DIS 3166-2, Codes for the representation of names of countries and their subdivisions -- Part 2: Country subdivision code ISO/DIS 3166-3, Codes for the representation of names of countries and their subdivisions -- Part 3: Code for formerly used names of countries Paul Eggert replied on 1998-08-08: > Why not just stick with the names already in the Olson database, > preceded by `/' if necessary for the new standard? The Olson names > are widely used existing practice, and I don't see a technical reason > to change them. I agree that naming a time zone after the most populated city within that time zone is a very flexible and sound approach. The only thing that irritates me about the Olson/Eggert tz names is that they are all prefixed by the continent name, which I feel is redundant information. Is there really a good rationale why it has to be "Europe/Berlin" for the German time zone and not just "Berlin". I know that the tz database is structured into several per-continent files, but if we propose these names as a more widely used standard, does the tz source file name really have to be a part of it? If there is not a very good rationale for the continent part of the names used in the tz database and if they are only an implementation kludge for allowing to split the database into several smaller files, then I suggest we consider dropping the continent names quickly (which can certainly be done in some backwards compatible manner). Apart form this detail, the tz database names are certainly the best scheme for naming time zones that I have seen so far and, like Paul, I am very skeptical about inventing a new one based on political boundaries. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: From Antoine.Leca at renault.fr Mon Aug 10 09:56:18 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Mon, 10 Aug 1998 11:56:18 +0200 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt References: Message-ID: <35CEC3C2.B80C955@renault.fr> Markus Kuhn wrote: > > Keith Moore wrote on 1998-08-08: > > (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX > > is the iso 3166 country code and yyy is a political subdivision > > within that country. In many cases just /XX suffices. > > I don't know whether you already know that there exists a > new ISO 3166-2 draft standard, which defines ISO alpha codes for > regional subdivisions within countries (e.g., the states in US and the > bundesl?nder in DE): As Paul explained, this might be inappropriate. For example, the finest degree for Indiana according to ISO DIS 3166-2 is US-IN, and this does not accord with current practice. OTOH, there is Europe or the Western Indies... take a look below! > I agree that naming a time zone after the most populated city within > that time zone is a very flexible and sound approach. The only thing > that irritates me about the Olson/Eggert tz names is that they are all > prefixed by the continent name, which I feel is redundant information. > Is there really a good rationale why it has to be "Europe/Berlin" for > the German time zone and not just "Berlin". First, I should say that I see no reason to invent a new scheme: better to not always reinvent the wheel! Well, my problem is that, *in the view of the iCalendar protocol*, adding a different entry for each country may be an unnecessary burden. So I think that the CET (or MEZ) timezone ought to be named "/Paris" (or "/Berlin", if Berlin is more populated than Paris), instead as the current count: Africa/Ceuta Arctic/Longyearbyen Europe/Amsterdam Europe/Andorra Europe/Belgrade Europe/Berlin Europe/Bratislava Europe/Brussels Europe/Budapest Europe/Copenhagen Europe/Gibraltar Europe/Ljubljana Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Monaco Europe/Oslo Europe/Paris Europe/Prague Europe/Rome Europe/San_Marino Europe/Sarajevo Europe/Skopje Europe/Stockholm Europe/Tirane Europe/Vaduz Europe/Vatican Europe/Vienna Europe/Warsaw (currently questionable) Europe/Zagreb Europe/Zurich to a grand total of 31 entries! Please note that Keith pointed out the number of aliases in the tz database. Paul's answer lead me to think he understood it as the concept of "Link" that is here for backward compatibility reasons. But links are easy to skip; this is not the same game when one has to identify "Europe/London" and "Europe/Lisbon", that have very different history as timezones, but that are now equal, and also equal in the foreseable future. I believe that we should try to keep a minimum number of timezones, at least to not have to worry small implementations, and to keep the requirements on network traffic as small as possible. Antoine From Antoine.Leca at renault.fr Mon Aug 10 09:28:21 1998 From: Antoine.Leca at renault.fr (Antoine Leca) Date: Mon, 10 Aug 1998 11:28:21 +0200 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt References: <199808090216.WAA17388@spot.cs.utk.edu> <199808090627.XAA15475@shade.twinsun.com> Message-ID: <35CEBD35.52828B7F@renault.fr> Keith wrote: > How important is it for iCalendar timezones to work before 1998? and Paul answered: > iCalendar should be able to handle the problems that occurred before > 1998, because it's likely that similar problems will occur after 1998. That is very true. In my eyes, that means that the naming scheme for timezones should be extensible. Right, Paul? > Besides, iCalendar should work for dates before 1998; I'd want to use > it that way myself. Why limit it to future dates? Well, that is another point. In my eyes, we should be able to use the mechanisms described in iCalendar for any use, including in the past (and I hope it successed on this way). OTOH, the aim here is to do a world-wide repository about timezones suitable for Internet scheduling, and here I believe the past problems will be an additional weight with no useful properties. Or should we have two repositories? As you pointed out, my goal is to do an automatic tool that "tranforms" the files at Olson database (tzdata19XXa.tar.gz, not the ones produced by zic) to a database in iCal format (and to Microsoft Win32's format as well). Therefore, be this database served by an Internel protocol, or be it used internaly with proprietary tools is IMHO a personal choice. Antoine From eggert at twinsun.com Mon Aug 10 22:03:14 1998 From: eggert at twinsun.com (Paul Eggert) Date: Mon, 10 Aug 1998 15:03:14 -0700 Subject: Time zone suggestions for draft-ietf-calsch-ical-08.txt In-Reply-To: <35CEBD35.52828B7F@renault.fr> (Antoine.Leca@renault.fr) References: <199808090216.WAA17388@spot.cs.utk.edu> <199808090627.XAA15475@shade.twinsun.com> <35CEBD35.52828B7F@renault.fr> Message-ID: <199808102203.PAA18454@shade.twinsun.com> Date: Mon, 10 Aug 1998 11:28:21 +0200 From: Antoine Leca the naming scheme for timezones should be extensible. Right, Paul? Yes. The number of time regions will increase with time. > Besides, iCalendar should work for dates before 1998; I'd want to use > it that way myself. Why limit it to future dates? the aim here is to do a world-wide repository about timezones suitable for Internet scheduling, and here I believe the past problems will be an additional weight with no useful properties. It might be reasonable for iCalendar to ignore transitions before, say, July 1998 when considering what regions to have in its world-wide repository. This would lower the number of regions considerably. But why bother? The existing tz data gets you back to 1970 for free. It should be slightly more work to start with July 1998 (because you'll have to coalesce regions, select canonical representatives, and so forth) than to start with January 1970 (which should be a simple data translation). Date: Mon, 10 Aug 1998 11:56:18 +0200 From: Antoine Leca "Europe/London" and "Europe/Lisbon", that have very different history as timezones, but that are now equal, and also equal in the foreseable future. That's not a good example, as Europe/London and Europe/Lisbon are currently distinct. Their TZNAMEs differ: Europe/London uses `GMT/BST', whereas Europe/Lisbon uses `WET/WEST'. (Also, when the liberals return to power in Portugal, they may well switch the clocks forward again. :-) However, I agree with your main point: the number of regions will decrease if we drop Europe/Berlin, Europe/Rome, etc. and standardize on Europe/Paris. Would this be acceptable politically, though? As Keith Moore pointed out, J. Random Windows user in, say, Berlin might be a bit upset if he has to point his browser at Paris to set his time zone. I believe that we should try to keep a minimum number of timezones, at least to not have to worry small implementations, and to keep the requirements on network traffic as small as possible. Can you estimate how much would be saved by going with a 1998 horizon versus a 1970 horizon? I don't think it would be all that much, but I don't know what the assumptions are. From olsona at dc37a.nci.nih.gov Tue Aug 11 03:28:35 1998 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NCI)) Date: Mon, 10 Aug 1998 23:28:35 -0400 Subject: tzdata1998g.tar.gz Message-ID: <43E124CC389ED111B18D00805FEA1E63BC4BB2@nihexchange2.nih.gov> The file ftp://elsie.nci.nih.gov/pub/tzdata1998g.tar.gz is now available; it incorporates the Lithuanian change provided by mgedmin at pub.osf.it; it also moves creation of the GMT link with Etc/GMT to "etcetera" (from "backward") to ensure that the GMT file is created even where folks don't want the "backward" links (as suggested by Paul Eggert). --ado From eggert at twinsun.com Tue Aug 11 05:58:30 1998 From: eggert at twinsun.com (Paul Eggert) Date: Mon, 10 Aug 1998 22:58:30 -0700 Subject: pending changes to tz database, mostly from the IATA In-Reply-To: <43E124CC389ED111B18D00805FEA1E63BC4BB2@nihexchange2.nih.gov> (olsona@dc37a.nci.nih.gov) References: <43E124CC389ED111B18D00805FEA1E63BC4BB2@nihexchange2.nih.gov> Message-ID: <199808110558.WAA20753@shade.twinsun.com> I am about to send out changes to the time zone database compiled mostly from data kindly abstracted from the IATA tables by Gwillim Law. Here is a verbal description. Please let me know if any of these changes seem bogus; otherwise, I'll send out a proposed patch shortly. * Quintana Roo switched from CST/CDT to EST/EDT; we assume this happened last fall. This requires a new entry, America/Cancun. * Chihuahua switched from CST/CDT to MST/MDT; we assume this happened this spring. This requires a new entry, America/Chihuahua. * Cuba has changed the rules again. The 1998 change dates are Mar 29 and Oct 25. Thereafter, the rules will be the same as the US, except that the time of switch is 00:00 instead of 02:00. * Haiti stopped observing DST this year. * Starting in 1999, Paraguay switches the last Sunday in February, not March 1. * Starting this year, Estonia uses the EU rules; i.e. it switches at 01:00 UTC (03:00 standard time), not 02:00 standard time. * tzdata1998g.tar.gz has a glitch: it moves the Lithuanian clocks back by an hour at 1998 Mar 29 02:00, waits an hour, and then moves them forward an hour when 02:00 comes by again. Also, the new rules are identical to EU. * Crimea switched from Moscow time back to EET/EEST; we assume it happened in March 1997. * Starting this year, Armenia observes DST again, using the same rules as Russia. * Starting last year, Azerbaijan observes DST, using rules like Russia's except with transition times at 01:00 instead of 02:00. * Starting last year, Kirgizstan adopted DST rules like Russia's, except with transition times at 02:30 instead of 02:00. * Last fall Libya converted from CET/CEST to EET with no DST. Its spring 1997 transition was April 4 at 00:00, not Mar 27 at 02:00. * Egypt's DST rules are the fourth Friday in April at 00:00 to the last Friday in September at 24:00. The current tz database has the rules as the last Friday in April at 01:00 to the last Friday in September at 03:00, due to my transcription errors the last time around. * New Caledonia stopped observing DST in 1997; it was just a 1-year experiment. * The Cook Islands stopped observing DST in 1991. (This claim is from the 1995 edition of Shanks, not from the IATA.) * For the capital of Kazakhstan, the name `Almaty' now has a 2-to-1 majority over the old Russian-derived name `Alma-Ata' in English-language prose, as measured by Alta Vista; so it's time to switch the name in the database, with a backward-compatibility link. From okellyd at logica.com Wed Aug 12 22:12:15 1998 From: okellyd at logica.com (O'Kelly, David) Date: Wed, 12 Aug 1998 18:12:15 -0400 Subject: Lat. / Long to timezone conversion Message-ID: To whom it may concern, I am currently trying to identify if there are any existing software products which can carry out a Latitude / Longitude conversion to the corresponding timezone. Initially I am concentrating on data for the U.S., Canada & Mexico and was wondering if any relevant or pertinent information may be available on this subject. Thank you for any help you can provide. - regards Dave David O'Kelly Principal Software Engineer Communications Division Logica Inc. tel + 1 415 288 5200 fax + 1 415 288 5299 email okellyd at logica.com From rthelen at netapp.com Fri Aug 21 23:16:37 1998 From: rthelen at netapp.com (Randy Thelen) Date: Fri, 21 Aug 1998 16:16:37 -0700 Subject: Possible Bug in INT_STRLEN_MAXIMUM macro Message-ID: <35DDFFD5.B1F1D688@netapp.com> The INT_STRLEN_MAXIMUM macro in lib/private.h used by, among other files, asctime.c, states in its comment field: /* ** 302 / 1000 is log10(2.0) rounded up. ... */ And then in the macro definition we find: #define INT_STRLEN_MAXIMUM(type) \ ... * 302 / 100 ... Me thinks this is not what was intended. Possibly it's an error, possibly it's the right thing. Could you send mail back telling me if this was on purpose? -- Randy Thelen Software Engineer Network Appliance, Inc. From Markus.Kuhn at cl.cam.ac.uk Sat Aug 22 20:51:38 1998 From: Markus.Kuhn at cl.cam.ac.uk (Markus Kuhn) Date: Sat, 22 Aug 1998 21:51:38 +0100 Subject: Revision of ISO C 9x Message-ID: The new ISO C draft is on . I think, the following message might be of interest to many here: ------- Forwarded Message Date: Sat, 22 Aug 1998 21:00:08 +0100 To: David R Tribble , Antoine.Leca at renault.fr, kuhn at cs.purdue.edu From: "Clive D.W. Feather" Reply-To: "Clive D.W. Feather" Subject: It's about time [sorry for the bad joke] I'm sorry I've taken so long to get back to people about this. This email is going to all the people who have expressed to me an interest in the C9X time functions. C9X CD2 (aka the FCD) is now published (it can be found on the DKUUG web site). It basically contains the same material in as CD1 did, though a few minor errors have been corrected and Keld's %O and %E modifiers have appeared. Everyone who's written to me has expressed dissatisfaction with some part or other of the current situation. Therefore I have a rather radical proposal to make: I suggest we write a complete new section that addresses all our issues, and arrange for at least two, and preferably three or more, National Bodies to submit it as part of their response to CD2. I'm willing to act as the core editor for this work, provided: - - people will write full pieces of text for me to drop in as needed; - - people won't object to my use of editorial powers to tidy up and keep the wording consistent. I can provide web space where I will keep the working drafts. I suggest we start with what's in CD2 as a common base, though being ready to drop pieces if that's what we agree. In the meantime, here's all the issues that I'm aware of that our text would need to handle: (1) Clear definition of canonicalisation of times. (2) Unambigous mechanisms for converting between UTC and TAI, and between time zones, and for determining which is in use. (3) Clearer definitions of things like strftime conversions (all of these are in CD2, so this is a no-op). (4) Ability to determine the precision of times (a ticks per second macro, perhaps). This should be guaranteed to be <= 1 second over some range. (5) Ability to determine the range of time_t, with guaranteed minimum limits. (6) A member in struct tmx for access to subsecond resolution, and possibly new formats to access it. (7) The meaning of struct tm to remain source and binary compatible with C89. (8) Clearer definition of what struct tm[x] values must be handled by implementations. (9) All new functions to be re-entrant. (10) Rethink future expandibility of struct tmx. (11) Portable form for transferring time values between programs and implementations. Anything else ? I've no objection to this message having wider circulation, but only to people who aren't going to require more education than there's time for. - -- Clive D.W. Feather | Regulation Officer, LINX | Work: Tel: +44 1733 705000 | (on secondment from | Home: Fax: +44 1733 353929 | Demon Internet) | Written on my laptop; please observe the Reply-To address ------- End of Forwarded Message From olsona at dc37a.nci.nih.gov Mon Aug 24 13:17:34 1998 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NCI)) Date: Mon, 24 Aug 1998 09:17:34 -0400 Subject: Possible Bug in INT_STRLEN_MAXIMUM macro Message-ID: <43E124CC389ED111B18D00805FEA1E63BC4BBC@nihexchange2.nih.gov> -----Original Message----- From: Randy Thelen [SMTP:rthelen at netapp.com] Sent: Friday, August 21, 1998 7:17 PM To: tz at elsie.nci.nih.gov Cc: guy at netapp.com Subject: Possible Bug in INT_STRLEN_MAXIMUM macro The INT_STRLEN_MAXIMUM macro in lib/private.h used by, among other files, asctime.c, states in its comment field: /* ** 302 / 1000 is log10(2.0) rounded up. ... */ And then in the macro definition we find: #define INT_STRLEN_MAXIMUM(type) \ ... * 302 / 100 ... Me thinks this is not what was intended. Possibly it's an error, possibly it's the right thing. Could you send mail back telling me if this was on purpose? -- Randy Thelen Software Engineer Network Appliance, Inc. The bad news is that the macro definition indeed fails to match the comment; the good news is that the error results in over-generous sizing of arrays designed to hold ASCII representations of numbers. I've changed the "100" in the "#define" to the correct "1000"; the change will show up in the next version of tzcode. --ado