- tz - lists.iana.org

RE: Html-ize the tz database?
by Chuck Ellis Feb. 28, 2001

Feb. 28, 2001

Gwillim-- Nice job with the web page, however temporary. It is hard to imagine this not being very useful, and (as you note) to a much broader audience as well. The tz mapping project is in fact proceeding ahead under Rives McDow's leadreship, and will result in a future web page(s) of its own. Since one of its sub-projects is an automated parser of the current tz archive sufficient to generate a standard (RDBMS) database output, there may well be an opportunity to share that db output with your web efforts. Chuck Ellis -----Original Message----- From: Gwillim Law [mailto:gwil@mindspring.com] Sent: Wednesday, February 28, 2001 4:03 AM To: tz(a)elsie.nci.nih.gov Subject: Html-ize the tz database? Recently, this mailing list has discussed the perceived need for standardized time zone abbreviations. There has also been some talk about putting the boundaries of time zones into a GIS (Geographic Information System) format. Several people have volunteered to help with that task. These issues are not new; they've come up repeatedly in the past. I've just now posted a few sample Web pages to display data from the tz database in a more accessible format. This applies particularly to the geographic extent of time zones, which is hidden in comments in tzdata2000h. I invite anyone who is interested to visit http://www.mindspring.com/~gwil/tz.html and browse around. Questions to keep in mind: Are the sample pages the best way of displaying the data? Would they be a useful resource for the other tasks mentioned above? Is it feasible to maintain a Web site like this in synch with the tz database? Gwillim Law

1 0

FW: DST in Paraguay
by Olson, Arthur David (NCI) Feb. 27, 2001

Feb. 27, 2001

Gerd Knops is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Gerd Knops [mailto:gerti@bitart.com] Sent: Tuesday, February 27, 2001 2:38 PM To: tz(a)elsie.nci.nih.gov Subject: DST in Paraguay Hello, I (remotely) operate a server in Paraguay, and people there tell me that the timezone rules are incorrect. Paraguay changes to DST on the first Sunday in March, NOT on the last Sunday in February as the current rules still say. Sadly I do not have an official source to pint to. ... Thanks and regards -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gerd Knops INTERFAX VP of Engineering Questions: questions(a)interfaxx.com gknops(a)interfaxx.com Trouble reports: trouble(a)interfaxx.com

2 1

DST in Paraguay
by Gerd Knops Feb. 27, 2001

Feb. 27, 2001

Hello, I (remotely) operate a server in Paraguay, and people there tell me that the timezone rules are incorrect. Paraguay changes to DST on the first Sunday in March, NOT on the last Sunday in February as the current rules still say. Sadly I do not have an official source to pint to. Also please note that the latest tzdata files on you ftp server have a date that is somewhat in the future (December 2001). Thanks and regards -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gerd Knops INTERFAX VP of Engineering Questions: questions(a)interfaxx.com gknops(a)interfaxx.com Trouble reports: trouble(a)interfaxx.com

1 0

Copyright on the zoneinfo files?
by ira＠ascent.com Feb. 23, 2001

Feb. 23, 2001

What is the copyright on the tzdata2000h.tar.gz compilation? I noted no copyright info, and no marks that it was in the public domain :(. Thanks, -Ira

1 0

Re: time zone geography
by CHancuff＠aol.com Feb. 20, 2001

Feb. 20, 2001

I'd be happy to help, as long as I don't have to do the Soviet States or Brazil. :-) Let me know what I can do. Cliff Hancuff www.ClearDaySoftware.com

2 1

Time Zone Map
by Chuck Ellis Feb. 19, 2001

Feb. 19, 2001

Thanx to Rives McDow, Cliff Hancuff and Chris Sells for their generous offers to assist with the building and maintenance of a digital time zone map synchronized to the tz data maintained by this group. We will do our best to keep the full tz list updates as to progress, and post various mapfiles and applets to the group as they become available. I will follow up with these gentlemen directly. Chuck Ellis chuck_ellis(a)msn.com

1 0

FW: time zone geography
by Olson, Arthur David (NCI) Feb. 18, 2001

Feb. 18, 2001

-----Original Message----- From: Chuck Ellis [mailto:cellis@gaz.com] Sent: Friday, February 16, 2001 5:45 PM To: Olson, Arthur David (NCI); 'tz (E-mail)' Subject: time zone geography I have worked on the subject of time zone geography in the past (with tz's data) and actually had gotten thru to the point of generating a low-scale (~ 1:2MM) world map of the (I believe in 1998 it was 305) unique geographic zones. Since the zones were boundary objects in a GIS application, DST rules were applied dynamically, so the actual unique boundary count changed depending on date and time. I interject myself into the list discussion at this point because geography is simply a special case in relation to any proposed tz-focused software application that is going to deal with it. Even the issue of whether an area code is in a particular time zone or not is non-trivial. "Area Codes" are a North American 'thing', specifically defined by the North American Numbering Plan (NANP, managed by Bell). The rest of the world uses a Country-Code/City-Code system. The point is relevant because the geography of NANP boundaries is reasonably well characterized into a contiguous set of boundary polygons, with some "overlays" of identical boundaries where such overlays exist. Therefore, what particular zone(s) are relevant to a time zone in the NANP system is a matter of quite precise geographic calculation: one overlays the area code boundary map onto the time zone boundary map, and reads back the relevant "object contains" and/or "object intersects" set of time zones. Perfectly likely that a NANP area code completely contains one tz (e.g., Indianapolis is the summer), and intersects in some proportion another (e.g., Chicago). In the rest of the world, it can get quite messy. City-Code boundaries are well-characterized in some countries (e.g., France), and utterly nonexistent in many more (e.g., Burundi). The best one will be able to do in these situations is to default to using a "centroid" (the approximate geographic center of a city or town) and simply reading back which tz those coordinates fall within. The larger issue is not, of course, area codes, but any geography. It's a long list, but is best organized into three natural classes of geometric objects-- points, lines (including polylines), and polygons (including closed curves). The most relevant polygons include political, civil, administrative, telcomm, marketing, cadastral (property), statistical, media and those from the natural sciences. Common examples are country/state, city, area code, Designated Marketing Area, broadcast signal surfaces, lakes, zip codes, etc. Line and polyline objects can include roads, rivers (depending on resolution and scale), rail, power and fence line, pipeline, faultline and many more. Point objects are even more numerous, but certainly start with a "gazeteer", or roster of city/town names and coordinates, and progress to physical objects (towers, buildings, wells, etc.) to the very spot you happen to be sitting at right now. It is reasonable to imagine almost any type of geographical object, and want to know-- "What time zone is it in ?" Any application that is going to answer this question does not need to reinvent the wheel and write code to analyze overlaps, intersections, contains or any other "standard" GIS (geographical information system) function, including simply rendering and printing. There are hundreds of GIS systems out there, and even more code tools to embed particular functions into "your" app. The real challenge is on two ends of the issue-- the time zone "map", such as needs to be created and maintained; and the "map" (or at least digital embodiment therein) of whatever geographic object(s) are to be compared against the time zone map. For example, to determine what time zone(s) a particular NANP area code lies in, we need a digital map of that area code, the digital map of the world's time zones, and any GIS software or application containing such functions. Digital maps of nearly everything and everywhere are pretty widely available. Most addresses can be quickly "geocoded", or assigned lat/lon coordinates-- which is a digital map of that address. Since almost any geographical object's map can be purchased or downloaded with relative ease (cost notwithstanding), the map that is missing is, of course, a current time zone map. As I have pointed out in this discussion some years ago, a complete and current time zone map holds enormous power and utility for many (if not most) of the readers of this discussion list. One can purchase the GNIS CD-ROM containing the official names and coordinates of over 4 million cities, towns, villages, places, etc. in the world; overlay this file on a world time zone map; and in approximately 2 to 3 minutes on a Pentium PC, assign the proper time zone to all 4 million places. It's a little more complicated with boundary (polygon) overlays, but you get the idea. I am willing to devote some more time to trying to create the fundamental tz map that is needed for the generalized application that Arthur is discussing, but it is too much for one person alone, and really requires an organized effort to maintain its currency against the ever-changing tz database. I would ask at this time if there are any volunteers out there with some GIS or database skill that would help, and if there are enough responses, perhaps we could proceed to a more permanent group of focused volunteers. Initially, we would not tackle historical zones-- the current stuff is hard enough to keep track of ! Chuck Ellis chuck_ellis(a)msn.com -----Original Message----- From: Olson, Arthur David (NCI) [mailto:olsona@dc37a.nci.nih.gov] Sent: Friday, February 16, 2001 3:48 PM To: tz (E-mail) Subject: RE: What is a time zone? The existing public-domain time zone stuff lets you know how to represent local time if you provide the identity of the set of rules that apply. Recent mail has dealt with the matter of handling things such as geographic locations or phone system area codes. My sense is that layered software is the way to go. The bottom level turns a time-zone identifier into a representation of the rules that apply. Built on top of this are packages that take different forms of input (phone system area code, geographic location) and deliver up time-zone identifiers. The existing time-zone stuff is a bottom level. And there might be multiple higher levels--for example: topmost geographic location to phone system area code middle phone system area code to time zone identifier bottom time-zone identifier to rules that apply The organization of the higher levels would, of course, be immaterial to what goes on at the bottom level. A consideration in determining the time-zone identifiers to use in such a setup is the independent usability of the bottom level. The existing time zone stuff uses identifiers of the form big-geographic-region/city; this allows some meaningful applications (such as setting the local time to be used on a computer) without recourse to a higher level (proof by existence). There are other considerations as well (technological, political, technological, astrological...). And determining what to use as a time-zone identifier ought not be done in a vacuum: if the same identifier can be used for other purposes, we've simplified our lives.

2 1

TZ database content
by Srinivas Nagaraj Feb. 18, 2001

Feb. 18, 2001

The TZ (zoneinfo) database comes installed with several operating systems like Linux, Solaris, etc. I have noticed the content of the TZ database varies between different versions of the same operating system and also between operating systems. This could have been because of when a snapshot of the TZ database was taken. Ofcourse, one significant difference is the actual name of the time zone. Depending on the content of the TZ database, the time zone name look different. Is it because the TZ database has evolved? I also noticed that the zone.tab file is not distributed on a number of installations. Was that operating system installation decision? Now my main question, is it an appropriate application specific common practice to use an application specific TZ database? That way the time zone names can be consistent, irrespective of where the application is installed? Thank you. Srini

23 44

RE: What is a time zone?
by Olson, Arthur David (NCI) Feb. 17, 2001

Feb. 17, 2001

The existing public-domain time zone stuff lets you know how to represent local time if you provide the identity of the set of rules that apply. Recent mail has dealt with the matter of handling things such as geographic locations or phone system area codes. My sense is that layered software is the way to go. The bottom level turns a time-zone identifier into a representation of the rules that apply. Built on top of this are packages that take different forms of input (phone system area code, geographic location) and deliver up time-zone identifiers. The existing time-zone stuff is a bottom level. And there might be multiple higher levels--for example: topmost geographic location to phone system area code middle phone system area code to time zone identifier bottom time-zone identifier to rules that apply The organization of the higher levels would, of course, be immaterial to what goes on at the bottom level. A consideration in determining the time-zone identifiers to use in such a setup is the independent usability of the bottom level. The existing time zone stuff uses identifiers of the form big-geographic-region/city; this allows some meaningful applications (such as setting the local time to be used on a computer) without recourse to a higher level (proof by existence). There are other considerations as well (technological, political, technological, astrological...). And determining what to use as a time-zone identifier ought not be done in a vacuum: if the same identifier can be used for other purposes, we've simplified our lives.

2 1

time zone geography
by Chuck Ellis Feb. 16, 2001

Feb. 16, 2001

I have worked on the subject of time zone geography in the past (with tz's data) and actually had gotten thru to the point of generating a low-scale (~ 1:2MM) world map of the (I believe in 1998 it was 305) unique geographic zones. Since the zones were boundary objects in a GIS application, DST rules were applied dynamically, so the actual unique boundary count changed depending on date and time. I interject myself into the list discussion at this point because geography is simply a special case in relation to any proposed tz-focused software application that is going to deal with it. Even the issue of whether an area code is in a particular time zone or not is non-trivial. "Area Codes" are a North American 'thing', specifically defined by the North American Numbering Plan (NANP, managed by Bell). The rest of the world uses a Country-Code/City-Code system. The point is relevant because the geography of NANP boundaries is reasonably well characterized into a contiguous set of boundary polygons, with some "overlays" of identical boundaries where such overlays exist. Therefore, what particular zone(s) are relevant to a time zone in the NANP system is a matter of quite precise geographic calculation: one overlays the area code boundary map onto the time zone boundary map, and reads back the relevant "object contains" and/or "object intersects" set of time zones. Perfectly likely that a NANP area code completely contains one tz (e.g., Indianapolis is the summer), and intersects in some proportion another (e.g., Chicago). In the rest of the world, it can get quite messy. City-Code boundaries are well-characterized in some countries (e.g., France), and utterly nonexistent in many more (e.g., Burundi). The best one will be able to do in these situations is to default to using a "centroid" (the approximate geographic center of a city or town) and simply reading back which tz those coordinates fall within. The larger issue is not, of course, area codes, but any geography. It's a long list, but is best organized into three natural classes of geometric objects-- points, lines (including polylines), and polygons (including closed curves). The most relevant polygons include political, civil, administrative, telcomm, marketing, cadastral (property), statistical, media and those from the natural sciences. Common examples are country/state, city, area code, Designated Marketing Area, broadcast signal surfaces, lakes, zip codes, etc. Line and polyline objects can include roads, rivers (depending on resolution and scale), rail, power and fence line, pipeline, faultline and many more. Point objects are even more numerous, but certainly start with a "gazeteer", or roster of city/town names and coordinates, and progress to physical objects (towers, buildings, wells, etc.) to the very spot you happen to be sitting at right now. It is reasonable to imagine almost any type of geographical object, and want to know-- "What time zone is it in ?" Any application that is going to answer this question does not need to reinvent the wheel and write code to analyze overlaps, intersections, contains or any other "standard" GIS (geographical information system) function, including simply rendering and printing. There are hundreds of GIS systems out there, and even more code tools to embed particular functions into "your" app. The real challenge is on two ends of the issue-- the time zone "map", such as needs to be created and maintained; and the "map" (or at least digital embodiment therein) of whatever geographic object(s) are to be compared against the time zone map. For example, to determine what time zone(s) a particular NANP area code lies in, we need a digital map of that area code, the digital map of the world's time zones, and any GIS software or application containing such functions. Digital maps of nearly everything and everywhere are pretty widely available. Most addresses can be quickly "geocoded", or assigned lat/lon coordinates-- which is a digital map of that address. Since almost any geographical object's map can be purchased or downloaded with relative ease (cost notwithstanding), the map that is missing is, of course, a current time zone map. As I have pointed out in this discussion some years ago, a complete and current time zone map holds enormous power and utility for many (if not most) of the readers of this discussion list. One can purchase the GNIS CD-ROM containing the official names and coordinates of over 4 million cities, towns, villages, places, etc. in the world; overlay this file on a world time zone map; and in approximately 2 to 3 minutes on a Pentium PC, assign the proper time zone to all 4 million places. It's a little more complicated with boundary (polygon) overlays, but you get the idea. I am willing to devote some more time to trying to create the fundamental tz map that is needed for the generalized application that Arthur is discussing, but it is too much for one person alone, and really requires an organized effort to maintain its currency against the ever-changing tz database. I would ask at this time if there are any volunteers out there with some GIS or database skill that would help, and if there are enough responses, perhaps we could proceed to a more permanent group of focused volunteers. Initially, we would not tackle historical zones-- the current stuff is hard enough to keep track of ! Chuck Ellis chuck_ellis(a)msn.com -----Original Message----- From: Olson, Arthur David (NCI) [mailto:olsona@dc37a.nci.nih.gov] Sent: Friday, February 16, 2001 3:48 PM To: tz (E-mail) Subject: RE: What is a time zone? The existing public-domain time zone stuff lets you know how to represent local time if you provide the identity of the set of rules that apply. Recent mail has dealt with the matter of handling things such as geographic locations or phone system area codes. My sense is that layered software is the way to go. The bottom level turns a time-zone identifier into a representation of the rules that apply. Built on top of this are packages that take different forms of input (phone system area code, geographic location) and deliver up time-zone identifiers. The existing time-zone stuff is a bottom level. And there might be multiple higher levels--for example: topmost geographic location to phone system area code middle phone system area code to time zone identifier bottom time-zone identifier to rules that apply The organization of the higher levels would, of course, be immaterial to what goes on at the bottom level. A consideration in determining the time-zone identifiers to use in such a setup is the independent usability of the bottom level. The existing time zone stuff uses identifiers of the form big-geographic-region/city; this allows some meaningful applications (such as setting the local time to be used on a computer) without recourse to a higher level (proof by existence). There are other considerations as well (technological, political, technological, astrological...). And determining what to use as a time-zone identifier ought not be done in a vacuum: if the same identifier can be used for other purposes, we've simplified our lives.

1 0

RE: etcetera patch
by Jesper Nørgaard Feb. 16, 2001

Feb. 16, 2001

Okay, that was much better. It is still complicated matter, but at least it was so clear that I got encouraged to make another suggestion for how to formulate it. I thought that the essence of "what many people expect" got lost in the examples. How about this: # We use POSIX-style signs in the Zone names and the output abbreviations, # even though this is the opposite of what many people expect. # POSIX has positive signs west of Greenwich, while most people expect # positive signs east of Greenwich. For example, TZ='Etc/GMT+4' corresponds # to 4 hours behind UTC (i.e. west of Greenwich) which many people would # expect to see as GMT-4. In Draft 5 of the next version of POSIX, the angle # bracket notation (which is not yet supported by the tz code) allows for # TZ='<GMT-4>+4'; if you also want abbreviations that conform to ISO 8601 # you can use TZ='<-0400>+4'. Thus the expected offset is kept within the # angle bracket (and not used for calculation) while the POSIX sign is kept # outside the angle bracked (and used for calculation). Regards, Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Programador/Analista CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 CIMMYT home page: http://cimmyt.cgiar.org Check out my free program World Time Explorer: http://timezone50.homepage.com ---------- From: Paul Eggert[SMTP:eggert@twinsun.com] Sent: Jueves 15 de Febrero de 2001 11:28 To: jnorgard(a)Prodigy.Net.mx Cc: tz(a)elsie.nci.nih.gov Subject: Re: etcetera patch > Date: Wed, 14 Feb 2001 22:21:35 -0600 > From: =?iso-8859-1?Q?Jesper_N=F8rgaard?= <jnorgard(a)Prodigy.Net.mx> > Resent-From: tz(a)elsie.nci.nih.gov > > "internal-style signedness" and "zic style"?? Reading the below utterings > just makes me bounce of the wall and scratch my head (but not at the same > time :-). OK, here's a draft rewording that I hope doesn't leave as many marks on your wall (and your head :-). # We use POSIX-style signs in the Zone names and the output abbreviations, # even though this is the opposite of what many people expect. # For example, TZ='Etc/GMT+4' corresponds to 4 hours behind UTC # (i.e. west of Greenwich); it is equivalent to TZ='GMT+4', # except that it uses the abbreviation "GMT+4" # whereas TZ='GMT+4' uses the misleading abbreviation "GMT". # TZ='Etc/GMT+4' is equivalent to the TZ='<GMT+4>+4' of Draft 5 of the next # version of POSIX, but the angle-bracket notation is not yet # supported by the tz code. With the Draft 5 notation, people who # prefer the traditional sign in abbreviations (where positive numbers # are east of Greenwich) can use TZ='<GMT-4>+4'; if they also want # abbreviations that conform to ISO 8601 they can use TZ='<-0400>+4'.

1 0

RE: etcetera patch
by Jesper Nørgaard Feb. 16, 2001

Feb. 16, 2001

"internal-style signedness" and "zic style"?? Reading the below utterings just makes me bounce of the wall and scratch my head (but not at the same time :-). Even though I have been on this mailing list for some time, I still have no idea what you are talking about. Wouldn't some plain english be in place here? Sorry for the grouch. It was actually meant to be constructive criticism. If you can't describe this without using a lot of words, insert examples in the sentences right after the keywords. Regards, Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Programador/Analista CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 CIMMYT home page: http://cimmyt.cgiar.org Check out my free program World Time Explorer: http://timezone50.homepage.com ---------- From: Paul Eggert[SMTP:eggert@twinsun.com] Sent: Miércoles 14 de Febrero de 2001 3:17 To: alex(a)agsm.edu.au Cc: tz(a)elsie.nci.nih.gov Subject: Re: etcetera patch > Date: Wed, 14 Feb 2001 18:03:54 +1100 > From: Alex LIVINGSTON <alex(a)agsm.edu.au> > ># We use POSIX-style signedness in the names and output, > ># internal-style signedness in the specifications. > > What is "internal-style signedness"? Would your "average" tz user know? How? It's zic style. I'll change "internal" to "zic-input". > ># ... With the Draft 5 notation, people who > ># prefer the traditional time zone sign can use TZ='<GMT-4>+4'. > > What is "the traditional time zone sign"? The sign where positive numbers are east of Greenwich. I'll change the wording here too. > What about UTC as opposed to GMT? The existing zone names all use "GMT" so I think it's better to use GMT in the examples. > Might you also say "people who prefer ISO-8601 compliant time-zone > signs can use TZ='<UTC-04:00>+4' instead"? That doesn't conform to either ISO 8601 or to d5. ISO 8601 does not allow the 'UTC'; d5 does not allow the ':'. However, TZ='<-0400>+4' would conform to both, I think; I'll add that example too. Thanks for your comments.

2 1

please tell me when
by MarieATOKC＠aol.com Feb. 15, 2001

Feb. 15, 2001

the time is that we change the clocks ahead for spring ? thank you ..Marie

1 0

FW: ZoneInfo.java
by Olson, Arthur David (NCI) Feb. 14, 2001

Feb. 14, 2001

Stuart D. Gathman is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Stuart D. Gathman [mailto:stuart@bmsi.com] Sent: Wednesday, February 14, 2001 5:50 PM To: tz(a)elsie.nci.nih.gov Subject: ZoneInfo.java You might wish to link to http://www.bmsi.com/java/#TZ It is a Java language reader for tz format zoneinfo files. -- Stuart D. Gathman <stuart(a)bmsi.com> Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 "Confutatis maledictis, flamis acribus addictis" - Mozart background song for the Microsoft "Where do you want to go from here?" commercial.

1 0

ZoneInfo.java
by Stuart D. Gathman Feb. 14, 2001

Feb. 14, 2001

You might wish to link to http://www.bmsi.com/java/#TZ It is a Java language reader for tz format zoneinfo files. -- Stuart D. Gathman <stuart(a)bmsi.com> Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 "Confutatis maledictis, flamis acribus addictis" - Mozart background song for the Microsoft "Where do you want to go from here?" commercial.

1 0

Brand New E-Mail pager for FR-EE! 27469
by bigjoe＠japan.com Feb. 14, 2001

Feb. 14, 2001

No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8546 Brand New E-Mail pager for FREE!

1 0

Re: etcetera patch
by Paul Eggert Feb. 14, 2001

Feb. 14, 2001

> Date: Fri, 9 Feb 2001 18:20:39 -0800 (PST) > From: Robbin Kawabata <Robbin.Kawabata(a)eng.sun.com> > > I think etcetera is OK.... On second thought you're probably right. This stuff is so obsolete now, changing it would probably add to confusion rather than subtracting it. > Note the comments in the file itself: > > # We use POSIX-style signedness in the names and output, > # internal-style signedness in the specifications. > # For example, TZ=Etc/GMT+4 corresponds to 4 hours _behind_ UTC; > # it is equivalent to TZ=GMT+4, which is implemented directly as per POSIX. Those comments are not quite right either, and they added to my confusion. TZ=Etc/GMT+4 is not exactly equivalent to TZ=GMT+4, because they result in different abbreviations. How about if we change the above comments to be something like this instead? # We use POSIX-style signedness in the names and output, # internal-style signedness in the specifications. # For example, TZ=Etc/GMT+4 corresponds to 4 hours _behind_ UTC; # it is equivalent to TZ=GMT+4, except that it uses the abbreviation "GMT+4" # whereas TZ=GMT+4 uses the misleading abbreviation "GMT". # TZ=Etc/GMT+4 is equivalent to the TZ='<GMT+4>+4' of Draft 5 of the next # version of POSIX, but the angle-bracket notation is not yet # supported by the tz code. With the Draft 5 notation, people who # prefer the traditional time zone sign can use TZ='<GMT-4>+4'.

3 3

Fw: What is a time zone?
by Thomas Carey Feb. 14, 2001

Feb. 14, 2001

great analysis, david. thanks. I think you hit the nail on the head about differences in approach to the problem. Of course in practical terms a simple model has some strengths in terms of user interface. Put another way - most calendaring applications dealing with timezones are concerned with coordinating events now and in the future - and assume further more that it is possible to present an interface which allows users to distinguish between timezones in different locales regardless of whether they might share a common abbreviation in popular usage. Then it is 'just' a matter of completeness to instantiate every timezone in use now, and to keep that current moving forward, while preserving the historical data. Then, given a localtime and a "timezone" (abstracted as a set of rules for computing offset from UTC) we can coordinate events around the globe. In fact it seems like that approach would work for historical events as well - as long as you could identify the timezone. Which is I guess the point you are making - it is much easier to go from locale to "timezone" than vice-versa, even in the present, and even if "timezone" is well defined for the user. Also I can see that you can better support a COMPLETE database with a locale based interface - the interface for exposing *every* enumerated timezone thoughout history would be overwhelming and unappreciated. tc ----- Original Message ----- From: "David Keegel" <djk(a)cyber.com.au> I think common usage outside this group is that a time zone has variable boundaries, and is something like the set of places which *currently* observe the same time (although perhaps US EST and CDT might be considered different time zones). In this model, counties in Kentucky change time zone, rather than creating a new time zone, when they switch. So translating this mindset to the computer world, if you are in Wayne County you would manually change your $TZ from US/Central to US/Eastern on 2000-10-29. Of course, this simplistic model has a fairly obvious problem. You can't compute times across a discontinuity like that in any sensible way, which is why this group has a different concept of what a time zone is - that it has a history attached and does not have variable boundaries (in theory). Might it reduce this confusion if the TZ group used something like "time zone history" or "time zone ruleset" instead of just "time zone", to distinguish it from the epheremal idea of "time zone" in popular usage? __________________________________________________________________________ David Keegel <djk(a)cyber.com.au> URL: http://www.cyber.com.au/users/djk/ Cybersource P/L: Unix Systems Administration and TCP/IP network management

1 0

RE: What is a time zone?
by Syed Sajjath Feb. 13, 2001

Feb. 13, 2001

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

2 1

UK/Concession Time
by Paul L. Allen Feb. 13, 2001

Feb. 13, 2001

Just grabbed the tz stuff for the first time in a year or two. My understanding of Clive Feather's post, which I no longer have a copy of, is that Cheriton Terminal runs on Concession Time (Concession comes from the "Channel Tunnel Concession") - the station clocks are set to Concesion Time. Concession time is formally defined to be the same as French Civil Time and uses the distinctive :) abbreviations of CT in the winter and CT in the summer. I am not sure about the police issue. There are special Rail Transport Police but I believe it's rare for them to be permanently located at a station. The normal police may also be called in to deal with matters. I'd expect the normal police would go by GMT/BST since they're trained to check their watches. I'd expect an RTP who had to travel to the terminal to deal with an incident to use GMT/BST for the same reason. If there are RTPs permanently stationed at the terminal, it could be that they'd set their watches to CT but it's anybody's guess how they'd record times. Anyway, it is a fact that the terminal operates on Concession Time. As such, if they have any Unix boxes there it's likely that they will be configured to run on Concession Time by pretending they're in the Europe/France timezone. We don't need a Europe/Concession zone but I think it's a nice touch to have one. At the very least, knowing about Concession Time is useful for astounding people in pubs. :) -- Paul

1 0

IERS Message No. 4
by central_bureau＠iers.org Feb. 12, 2001

Feb. 12, 2001

*************************************************************************** IERS Message No. 4 February 12, 2001 *************************************************************************** ----------------------- IERS EOP-PC and ICRS-PC ----------------------- Paris, 9 February 2001 Subject : Submissions for the 2000 IERS Annual Report Dear colleagues: You are invited to submit Earth orientation and reference frame results for annual analyses of the Earth Orientation Centre (EOP-PC) and of the ICRS Centre (ICRS-PC) for publication in the 2000 IERS Annual Report. ICRS-PC: CELESTIAL SYSTEMS AND FRAMES ===================================== The VLBI catalogues provided by the Analysis Centers will be analyzed and validated. New information will be used to check the ICRF-Ext.1, the current conventional celestial reference frame. Individual solutions will be used to study the effect of models, geometry, etc. We would appreciate that a special effort be made concerning the modeling and the adoption of the IERS Conventions. EOP-PC: EARTH ORIENTATION ========================= The EOP submission is unchanged with regard to last year submission. Analysis centers are invited to make their solutions using either the ITRF reference frame or deriving their own terrestrial frame that should be sent to the ITRF Bureau for consistency analyses. Specifications for the terrestrial frames submissions are provided by the ITRF Section: http://lareg.ensg.ign.fr/ITRF/ITRF-submit.html Long time series (over at least five years) tied to well described reference frames are extremely useful for the monitoring of the tie of IERS EOP and reference frames. Warning!!! ---------- A new EOP format was developed at the EOP-PC for homogeneity between the different techniques contributions. Please adopt this new format. DOCUMENTATION ============= To help you to prepare and send your contributions, various files are available at the anonymous ftp : hpiers.obspm.fr login : anonymous password : your e-mail address directory : iers/annreport/Call_2000AR guidelines : general description of the submission files techni_des : technical description of solutions format_rsc : format for submitting sets of radiosource coordinates format_eop : formats for submission of eop series You can also get the information on our Website: http://hpiers.obspm.fr/eop-pc/ HOW TO SUBMIT YOUR SOLUTIONS, THE SUMMARY AND THE DESCRIPTION FILES =================================================================== Send your files to iers(a)obspm.fr In case of large files put them on the following anonymous ftp (with acknowledgement to iers(a)obspm.fr) ftp hpiers.obspm.fr cd pub/annreport See the guidelines file for files name description. Your contribution is highly appreciated. Thank you for your cooperation. _________________________________________________________________________ | | | Send all files by 31 March 2001 | |_______________________________________________________________________| ***************************************************************************

1 0

Time in Falkland Islands and Moldova
by Jesper Nørgaard Feb. 12, 2001

Feb. 12, 2001

Hi. I have investigated time in Falkland Islands and Moldova, and have found discrepancies with the current tz database. Falkland Islands is represented like this in the tz database (2000h): # Falklands # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Falk 1937 1938 - Sep lastSun 0:00 1:00 S Rule Falk 1938 1942 - Mar Sun>=19 0:00 0 - Rule Falk 1939 only - Oct 1 0:00 1:00 S Rule Falk 1940 1942 - Sep lastSun 0:00 1:00 S Rule Falk 1943 only - Jan 1 0:00 0 - Rule Falk 1983 only - Sep lastSun 0:00 1:00 S Rule Falk 1984 1985 - Apr lastSun 0:00 0 - Rule Falk 1984 only - Sep 16 0:00 1:00 S Rule Falk 1985 1995 - Sep Sun>=9 0:00 1:00 S Rule Falk 1986 max - Apr Sun>=16 0:00 0 - Rule Falk 1996 max - Sep Sun>=8 0:00 1:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Atlantic/Stanley -3:51:24 - LMT 1890 -3:51:24 - SMT 1912 Mar 12 # Stanley Mean Time -4:00 Falk FK%sT 1983 May # Falkland Is Time -3:00 Falk FK%sT 1985 Sep 15 -4:00 Falk FK%sT The rules "Sun>=9" that was later substituted with "Sun>=8", and "Sun>=16", arose my curiosity. The rule "Sun>=9" means the Sunday after the Second Saturday which is pretty awkward to say the least (but possible), and not supported by Windows (which support First, Second, Third, Fourth and Last weekday of a given month). It was replaced in 1996 with the rule "Sun>=8" which means the Second Sunday which *is* supported by Windows. It just so happens that 1996 was the first year in several years back where it would make a difference which rule to use. With the first rule we would get the 15.th. September, while the second rule we would get the 8.th. September. Similarly looking at the rule "Sun>=16" it means the Sunday after the third Saturday, which is an awkward rule and not supported by Windows. I got the suspicion that it should have been "Sun>=15" instead, which means the third Sunday. It just happens that this gives a difference this year, because using the first rule sets the date to Sunday April 22, while the second rule gives Sunday April 15. I decided to investigate the matter. I found a page in Internet that is apparently the official Falkland Island governments web page, http://www.falklands.gov.fk/ In the page http://www.falklands.gov.fk/feedback.htm I entered my question about the planned DST for Falkland Islands this year. The account manager(a)figo.u-net.com responded me with the following: ===================== Begin Quote ========================== From: General Manager[SMTP:manager@figo.u-net.com] Sent: Lunes 22 de Enero de 2001 7:10 To: 'jnorgard(a)Prodigy.Net.mx' Subject: Time Zone INformation Thank you for contacting Falkland Islands Government. To help you with your enquiry, we can confirm the clocks revert back to Local Mean Time at 2 am on Sunday 15 April 2001and advance one hour to summer time at 2 am on Sunday 2 September. It is anticipated that the clocks will revert back at 2 am on Sunday 21 April 2002 and advance to summer time at 2 am on Sunday 1 September. I hope this helps you. Do contact us again if we can be of further assistance. Regards Falkland Islands Government Office, London ===================== End Quote ========================== This valuable peace of information gives us at least three details that doesn't correspond with the tz database: (1) Start and end time are 2 am in the morning (I assume local time) (2) My theory about "Sun>=15" instead of "Sun>=16" is apparently correct (3) The rule "Sun>=8" should actually be "Sun>=1" instead. I have sent a question about how far back this rule has been used (which will apparently be used in the years 2001 and 2002) but haven't received any answer yet. I will return to you with that information if I get an answer. Concerning Moldova: A person contacted me to inquire about if the extra time zone GMT+3 in Moldova for Tiraspol really was correct, since I was the only one he had seen using that. Any other sources he had seen was only using Chisinau GMT+2. The current information about Moldova in the tz database (2000h): # Moldova # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Chisinau 1:55:20 - LMT 1880 1:55 - CMT 1918 Feb 15 # Chisinau MT 1:44:24 - BMT 1931 Jul 24 # Bucharest MT 2:00 Romania EE%sT 1940 Aug 15 2:00 1:00 EEST 1941 Jul 17 1:00 C-Eur CE%sT 1944 Aug 24 3:00 Russia MSK/MSD 1990 3:00 - MSK 1990 May 6 2:00 - EET 1991 2:00 Russia EE%sT 1992 2:00 E-Eur EE%sT 1997 # See Romania commentary for the guessed 1997 transition to EU rules. 2:00 EU EE%sT Zone Europe/Tiraspol 1:58:32 - LMT 1880 1:55 - CMT 1918 Feb 15 # Chisinau MT 1:44:24 - BMT 1931 Jul 24 # Bucharest MT 2:00 Romania EE%sT 1940 Aug 15 2:00 1:00 EEST 1941 Jul 17 1:00 C-Eur CE%sT 1944 Aug 24 3:00 Russia MSK/MSD 1991 Mar 31 2:00 2:00 Russia EE%sT 1992 Jan 19 2:00 3:00 Russia MSK/MSD I decided to check it out with some searches in Internet, but didn't find anything remotely authoritative, but did find some english-speaking persons with e-mail that were apparently living in Tiraspol. I sent mails to 4 persons and got 2 replies: ===================== Begin Quote ========================== From: Moldavizolit[SMTP:moldavizolit@tirastel.md] Reply To: Moldavizolit Sent: Miércoles 24 de Enero de 2001 1:03 To: Jesper Nørgaard Subject: Re: Time in Tiraspol > Hello Jesper Nørgaard ! > >Tiraspol is on the same time as Chisinau (Kishinev, GMT+2) > Regards, > > Lubov ===================== End Quote ========================== ... and this one ===================== Begin Quote ========================== From: ??? ???????????[SMTP:mk@tirastel.md] Sent: Miércoles 24 de Enero de 2001 4:28 To: Jesper Nørgaard Subject: Re: Time in Tiraspol Hello, Yes, time in Tiraspol is on the same time as Chisinau (Kishinev, GMT+2) best ragards Dmitry Goncharenco ----- Original Message ----- From: Jesper Nørgaard To: 'mk(a)mk.tiraspol.net' Sent: Wednesday, January 24, 2001 5:13 AM Subject: Time in Tiraspol ===================== End

2 1

California considering daylight-saving time extension
by Eric Ulevik Feb. 10, 2001

Feb. 10, 2001

http://www.dailynews.com/news/articles/0201/10/new02.asp

1 0

FW: etcetera patch
by Olson, Arthur David (NCI) Feb. 9, 2001

Feb. 9, 2001

Semen A. Ustimenko is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Semen A. Ustimenko [mailto:semenu@online.sinor.ru] Sent: Tuesday, January 16, 2001 3:30 PM To: tz(a)elsie.nci.nih.gov Subject: etcetera patch Hi! I've discovered that definition for GMT+N anf GMT-N are just wrong. I.e. setting zone to GMT+6 you really get -6 hours offset from GMT. And this is quite correct as is defined in etcetera file! So, suppose follwoing patch worth commiting. Index: src/share/zoneinfo/etcetera =================================================================== RCS file: /usr/home/ncvs/src/share/zoneinfo/etcetera,v retrieving revision 1.1.2.4 diff -c -r1.1.2.4 etcetera *** src/share/zoneinfo/etcetera 1999/01/21 21:35:07 1.1.2.4 --- src/share/zoneinfo/etcetera 2000/12/04 15:14:56 *************** *** 37,65 **** # zic -l GMT-12 # so we moved the names into the Etc subdirectory. ! Zone Etc/GMT-14 14 - GMT-14 # 14 hours ahead of GMT ! Zone Etc/GMT-13 13 - GMT-13 ! Zone Etc/GMT-12 12 - GMT-12 ! Zone Etc/GMT-11 11 - GMT-11 ! Zone Etc/GMT-10 10 - GMT-10 ! Zone Etc/GMT-9 9 - GMT-9 ! Zone Etc/GMT-8 8 - GMT-8 ! Zone Etc/GMT-7 7 - GMT-7 ! Zone Etc/GMT-6 6 - GMT-6 ! Zone Etc/GMT-5 5 - GMT-5 ! Zone Etc/GMT-4 4 - GMT-4 ! Zone Etc/GMT-3 3 - GMT-3 ! Zone Etc/GMT-2 2 - GMT-2 ! Zone Etc/GMT-1 1 - GMT-1 ! Zone Etc/GMT+1 -1 - GMT+1 ! Zone Etc/GMT+2 -2 - GMT+2 ! Zone Etc/GMT+3 -3 - GMT+3 ! Zone Etc/GMT+4 -4 - GMT+4 ! Zone Etc/GMT+5 -5 - GMT+5 ! Zone Etc/GMT+6 -6 - GMT+6 ! Zone Etc/GMT+7 -7 - GMT+7 ! Zone Etc/GMT+8 -8 - GMT+8 ! Zone Etc/GMT+9 -9 - GMT+9 ! Zone Etc/GMT+10 -10 - GMT+10 ! Zone Etc/GMT+11 -11 - GMT+11 ! Zone Etc/GMT+12 -12 - GMT+12 --- 37,65 ---- # zic -l GMT-12 # so we moved the names into the Etc subdirectory. ! Zone Etc/GMT-14 -14 - GMT-14 # 14 hours ahead of GMT ! Zone Etc/GMT-13 -13 - GMT-13 ! Zone Etc/GMT-12 -12 - GMT-12 ! Zone Etc/GMT-11 -11 - GMT-11 ! Zone Etc/GMT-10 -10 - GMT-10 ! Zone Etc/GMT-9 -9 - GMT-9 ! Zone Etc/GMT-8 -8 - GMT-8 ! Zone Etc/GMT-7 -7 - GMT-7 ! Zone Etc/GMT-6 -6 - GMT-6 ! Zone Etc/GMT-5 -5 - GMT-5 ! Zone Etc/GMT-4 -4 - GMT-4 ! Zone Etc/GMT-3 -3 - GMT-3 ! Zone Etc/GMT-2 -2 - GMT-2 ! Zone Etc/GMT-1 -1 - GMT-1 ! Zone Etc/GMT+1 1 - GMT+1 ! Zone Etc/GMT+2 2 - GMT+2 ! Zone Etc/GMT+3 3 - GMT+3 ! Zone Etc/GMT+4 4 - GMT+4 ! Zone Etc/GMT+5 5 - GMT+5 ! Zone Etc/GMT+6 6 - GMT+6 ! Zone Etc/GMT+7 7 - GMT+7 ! Zone Etc/GMT+8 8 - GMT+8 ! Zone Etc/GMT+9 9 - GMT+9 ! Zone Etc/GMT+10 10 - GMT+10 ! Zone Etc/GMT+11 11 - GMT+11 ! Zone Etc/GMT+12 12 - GMT+12

3 2

Microsoft Timezone User Interface
by Srinivas Nagaraj Feb. 9, 2001

Feb. 9, 2001

Hello, I am relatively new to this discussion, and I am interested to know your thoughts on the following. The Microsoft Windows Time Zone User Interface allows you to use (with a check box) daylight savings in all time zones where applicable. I was wondering as to why they made that a user modifiable option? They could for example have had two Eastern Standard Time (EST) pulled down options, one using daylight savings, and the other not using daylight savings (for same parts of Indiana). Is it for flexibility? or .....? Thank you. Srini

2 1