May 1997 - tz - lists.iana.org

spam
by ado May 27, 1997

May 27, 1997

Right now the time zone list is handled on a UNIX system; mail sent to "tz" gets forwarded (as a result of an "/etc/aliases" entry) to the addresses that appear in a file maintained by hand. If anyone can recommend a filtering program to use in the /etc/aliases entry, I'd appreciate hearing from you by electronic mail to arthur_david_olson(a)nih.gov --ado

1 0

Re: Re: Answers to questions, spam problems
by Dave Skinner May 27, 1997

May 27, 1997

> > Dave Skinner writes: > > > I agree that the spammers should be stopped, and if that takes > > > monitoring postings before they are actually posted, then so be it. > > > Chris Carrier writes: > > The only posts that would be monitored/moderated would be those from > > non-tz subscribers; not an undue burden. > Dik Winters writes: > I do not believe that. Currently spammers are using throw-away accounts, > shortly they will be using throw-away subscribtions. Not to dwell on this subject for too long, but I tend to agree with Chris Carrier on this one, and I'm the one at the top of this sequence of quotes. I grew up where burglaries were rare, but did occur. So, we locked our doors when we left the house. By comparison, we had friends in rural Ohio who never locked their doors when they left the house; there was no need. Now, I live in one of the maze of cities and towns that make up the greater Los Angeles area, and there are many areas, that fortunately do not include the one in which I live, but which are nearby, that not only feel they need to lock their doors, but also the need to put bars on their own windows, which can really get in the way of the fire department should there be a fire. The point of this analogy is that letting subscriber articles through unmonitored is working for now as witnessed by Chris Carrier writes: > So the list moderator decided to require that all posts sent from non- > subscribers be cleared through him. Posts from subscribers are still > automatically posted. No spam has appeared on the list since this > policy was adopted five months ago. I would say we have been, up till now, operating like my friends in Ohio. At the point where we feel the spam has gotton bad enough, and I am not sure we are at that point yet, but if and when we get to that point, then we should do the equivalent of locking our doors, i.e. we probably should have non-subscriber articles be monitored. If that gets the job done, then we should leave our anti-spam security measures at that level. At a later time if the spammers start using "throw-away subscriptions" as Dik Winters fears, and if the spam again becomes a significant problem, then we should regretfully do the equivalent of adding the bars to our own windows as well. We can always take this more draconian precaution, but I really hate giving up freedoms, and adding work to the maintainers of this list, unless it really becomes necessary. We should not make the cure worse than the disease. Although I am switching analogies as I state the following, I really do not think we should have representatives of the post office, so to speak, censoring our mail simply to avoid that portion which is junk mail. Dave Skinner

1 0

Re: Answers to questions, spam problems
by Dik.Winter＠cwi.nl May 25, 1997

May 25, 1997

> >I totally agree that the spammers should be stopped, and if that takes > >monitoring postings before they are actually posted, then so be it. > > The only posts that would be monitored/moderated would be those from non-tz > subscribers; not an undue burden. I do not believe that. Currently spammers are using throw-away accounts, shortly they will be using throw-away subscribtions. dik

1 0

Answers to questions, spam problems
by Chris Carrier May 24, 1997

May 24, 1997

Joe Celko [71062.1056(a)compuserve.com] quotes me: >>... the growth of standard time laws. Don't remember much more about it, >>but the full story is in "The History of American Time." >Would you mind giving me the full reference for that book? Unfortunately I don't have a full reference. I remember it came out about 1990, and forget the author's name. It deals mostly with the establishment of standard time, with the last chapter devoted to daylight time. sharris(a)apple.com also quotes me: >Another, related mailing list I subscribe to, CALNDR-L, >run by Rick McCarty of East Carolina University, was suffering from spam >Can you tell me a bit about this list you are referring to, and how one can >subscribe? The list is about calendars: actual and proposed, along with related subjects, like the number of days in a year and the change in that number (which of course is related to leap seconds). It's been up since last October. To subscribe, send a one-line email SUBSCRIBE CALNDR-L to LISTSERV(a)ECUVM.CIS.ECU.EDU. In December members of CALNDR-L started to receive spam from various sources. So the list moderator decided to require that all posts sent from non- subscribers be cleared through him. Posts from subscribers are still automatically posted. No spam has appeared on the list since this policy was adopted five months ago. Although it is possible that a subscriber could send spam, anyone who did would be expelled from the list and everyone on the list is a sensible person who would not do such a thing. I would advocate a similar policy here on tz to stop spam. Dave Skinner (dave(a)kirdu.jpl.nasa.gov) wrote: >I totally agree that the spammers should be stopped, and if that takes >monitoring postings before they are actually posted, then so be it. The only posts that would be monitored/moderated would be those from non-tz subscribers; not an undue burden. Chris

1 0

Re: ["Matthias Urlichs" <smurf@work.smurf.noris.de>] POSIX vs "right" time difference
by Paul Eggert May 23, 1997

May 23, 1997

Date: Thu, 22 May 1997 15:06:40 +0200 (Funky) From: "Matthias Urlichs" <smurf(a)work.smurf.noris.de> the POSIX time zone files ignore leap seconds, i.e. are based on GMT, while the 'right' timezone take leap seconds into account. The base difference between those, according to "date", is 20 seconds (soon to be 21). That's wrong. The difference between UTC and TAI ("atomic time") is actually 30 (soon to be 31) seconds; the 10 seconds come from the fact that UTC and TAI were initially synchronized in 1958, and in 1972 it was realized that they've drifted apart... instant 10-second insertion. That's not what happened. There was no 10-second insertion in 1972. The atomic timekeepers didn't wake up from a 14-year sleep and notice that the world's clocks had drifted! Here's a more accurate description of what happened. Before 1972, UTC was adjusted continuously, without using leap seconds. At the moment of the POSIX Epoch (1970-01-01 00:00:00 UTC), UTC and TAI differed, not by an integral number of seconds, but by a fractional number. The difference between UTC and TAI did not become an integer until 1972, when the leap second regime was introduced. Therefore, it is impossible, on a system with integral time_t, to simultaneously support both "right" and POSIX times accurately before 1972. In some sense, the "right" approach yields undefined times before 1972, since the "right" approach assumes leap seconds. But we could attempt to extend the "right" approach by guessing what it would have been like had it existed. That is, with an integral time_t, we could _approximate_ "right" times before 1972 by consulting historical tables of the difference between UTC and TAI, and rounding to the nearest integer. This is unsatisfactory (not least because such tables understandably do not go back to times before atomic clocks were introduced!), but it is probably the best that we can do with the "right" approach assuming integral time_t. I view this improvement as a low-priority task since very few people use the "right" approach these days; the people who care about leap seconds are using other interfaces. Furthermore, the philosophy of the tz package is to describe times as they actually appeared at the time; it's hard to combine this with the notion of gedanken atomic clocks ticking away in, say, 1901.

1 0

Re: How to stop spammers ...
by Dave Skinner May 22, 1997

May 22, 1997

I totally agree that the spammers should be stopped, and if that takes monitoring postings before they are actually posted, then so be it. Dave Skinner

1 0

BC case, Oliver Wendell Holmes
by Chris Carrier May 22, 1997

May 22, 1997

Fascinating post about British Columbia time. It reminds me of something Oliver Wendell Holmes, when he was on the Massachusetts Supreme Court, ruled on some date after 1883-11-18 but before the adoption of the Standard Time Act of 1918. The LMT of a point in Massachusetts is approximately GMT-4:45, and EST=GMT-5:00. Holmes in his majority opinion wrote that the time of day specified in contracts, etc... was LMT regardless of what the railroads said, unless a governmental body chose to specify otherwise, which no doubt spurred the growth of standard time laws. Don't remember much more about it, but the full story is in "The History of American Time."

1 0

How to stop spammers on tz
by Chris Carrier May 22, 1997

May 22, 1997

jones(a)mr.med.ge.com wrote: >Direct [ i.e. junk ] E-Mail advertising is perhaps the stupidest marketing >idea ever. I completely agree. Another, related mailing list I subscribe to, CALNDR-L, run by Rick McCarty of East Carolina University, was suffering from spam attack until the moderator closed the list to all non-subscribers. A non- subscriber now has to write the moderator, and if the post is relavent, it is posted; if it is spam, it is now. I think ado should do the same thing here. Chris Carrier

1 0

legal reasoning and time-of-day
by 699156＠ican.net May 21, 1997

May 21, 1997

This isn't strictly on-topic, but I though readers of this list would be interested in a recent summary trial in the Supreme Court of British Columbia, Smith Bros. & Wilson (B.C.) Ltd. v. British Columbia Hydro and Power Authority. A key issue was the legal meaning of the term "11:00 a.m.". The ambiguity arose because a time of day expressed in that format is ambiguous: it can refer either to an instant (i.e. exactly eleven hours after midnight) or a 60-second period (i.e. the period more than eleven hours after midnight but less than eleven hours one minute after midnight). Here, a $13-million contract turned on this fine distinction. The defendant B.C. Hydro had issued tender instructions for the contract stating a closing time of "11:00 a.m. local time". The bid of the plaintiff Smith Bros. and Wilson was submitted when B.C. Hydro's clock said 11:01, and stamped accordingly. However, at trial, there was evidence from one of B.C. Hydro's own engineers that the clock was approximately one minute fast, compared to Pacific Standard Time determined with reference to the U.S. Naval Observatory clock in Washington D.C. This part of the judgment makes interesting reading, because the engineer had done the testing for his report two weeks after the day the tenders were due, but was still able to find (based on certain assumptions) the clock's differential on the tendering day. Since the clock was about a minute fast, the plaintiff's bid was actually submitted at 11:00, not 11:01. But this still wasn't good enough, because the court held that 11:00, in its everyday meaning of "the period from 11:00:00 to just before 11:01:00", was not what was meant by the tender instructions. Rather, the tender instructions were read to mean bids could be submitted up to 10:59:59, but not one second after that. The judge stated: [33] B.C. Hydro and Smith Bros. cited cases in which expressions like "until the 1st day of July next", for example, were used. See: Re Smith and McPherson (1921), 51 O.L.R. 457 (App. Div.). The purport of those decisions is that the whole of the named day was intended to be included. The argument is that if the naming of a day imports the whole of that day, the stating of time in hours and minutes should import the whole of that minute as being included in the calculation of the time limit. I do not agree with this analogy. In my opinion, 11:00 a.m. describes a precise point in time, not the time that exists between 11:00 a.m. and 11:01 a.m., whereas, when a date is stated, it is common knowledge and usage that that named day is a 24 hour period from midnight to midnight. The full text of the reasons for judgment is available on the web at http://www.courts.gov.bc.ca/jdb-txt/sc/97/03/s97-0302.txt and there is an article on the case in The Lawyer's Weekly, 21 March 1997, p. 16. M. Englander

1 0

Please remove tz@elsie.nci.nih.gov from your mailing list
by Rob Jones 4-6597 MR Sys May 21, 1997

May 21, 1997

Direct [ i.e. junk ] E-Mail advertising is perhaps the stupidest marketing idea ever. Think of how upset people would be if they received advertising through snail-mail that came postage due... That is how I feel when I receive junk Email. It costs disc space and time. And these costs are forced upon the recepient. It causes me to make note of the compaines that have sent me EMail and I refuse to send them any business. The above opinions are my own, not my employer's. And my apologies to those on the cc: that were not interested in this, but I thought it only fair to let you all know, since I am requesting something that impacts all on the list. -- Rob Jones P.S. If your company is good at promoting sites on the WEB, you should be able to promote your own without using such offensive tactics.

1 0

Is Your Web Site A Secret?
by owl＠owlsnest.com May 20, 1997

May 20, 1997

Is your web site the best kept secret on the Internet? We'll promote it to 50 search engines and indexes for $85 and complete the job in 2 business days. Satisfaction is guaranteed! If you have a great product, but are not getting many inquiries from your Web site, you may not be adequately listed on the Web's search engines and indexes. Millions of viewers daily use these facilities to find the products and services they are looking for. But if your site is not listed, no one will see it. Listings on most of these services are free. However, locating and filling out the forms required to get a listing can take several days, and most people just don't have the time to do it. That is why we offer a web site promotion service. WHAT'S THE DEAL? We will submit your site to 50 indexes and search engines for $85. We will accept the return of this E-mail, with the form below filled out, as an order. We will bill you upon completion of the promotion. Our terms are net 15 days from date of invoice. Satisfaction guaranteed! HOW LONG WILL IT TAKE? Generally, we complete the submissions within 48 hours of receiving your order. It can take any individual search engine or index up to three weeks to process your submission, although most are much faster. WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE PROMOTION? The list changes from time to time. This is our current list: Abaweb!, Alta Vista, Been There, BizWeb, Central Source Yellow Pages, Enterpreneurs on the Web, Excite, Four11, Galaxy, I-Network I-Systems Spiral Business Directory, I-World Web Pointer, Infoseek, Inktomi, Innovator's Network Yellow Pages, Internet Mall, Jayde Online Directory, Jumpcity, Jumper Hot Links, Linkmaster, Lycos, Magellan, Mega Mall, Net-Happenings, Net Navigator, Net Mall, NTG's List, NYNEX Big Yellow, One World Plaza, OnLine's WWWeb Index, Rex, Starting Point, Truenorth, URL Tree, Virtual Lynx, Web Point, WebCentral, Web Venture Hotlist, Webcrawler, Websurf, Win Mag/NetGuide Hotspots, WhatUSeek, Worldwide Announce Archive, WWW Business Yellow Pages, World Wide Yellow Pages, WWW Worm, YelloWWWeb. HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE? When we have completed the promotion, we will send you an HTML file as an attachment to your E-mail bill. Save this file to your disk, and view it through your Web browser. It provides links to the search engine we submitted your site to, plus any comments we received from them when we did it. ARE THERE ANY GUARANTEES? We do not require prepayment. Your satisfaction is guaranteed or you don't pay the bill. WHO IS OWL'S EYE PRODUCTIONS? We are a web site promotion company located at: Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Phone: (914) 278-4933 Fax: (914) 278-4507 Email: owl(a)owlsnest.com HOW DO I ORDER? The easiest way to order is by e-mail. Just hit the REPLY button on your e-mail program and fill out the following information. (This information will be posted to the search engines/indexes): Your name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: URL: http:// Site Title: Description (about 25 words): Key words (maximum of 25, in descending order of importance): Proofs (Where shall we e-mail proofs): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: We will bill via Email. (7519) Terms: By returning this document via Email, you agree as follows: You have the authority to purchase this service on behalf of your company. Terms are net 15 days. Accounts sent to collections will be liable for collection costs. You agree to protect and indemnify Owl's Eye Productions, Inc. in any claim for libel, copyright violations, plagiarism, or privacy and other suits or claims based on the content or subject matter of your site. WHAT HAPPENS NEXT? When we receive your order, we will input the information into our system, and send you a proof. After we process any corrections, we will run your promotion, capturing any comments from search engines as we go. We will incorporate these into an HTML-formatted report to you, which we will attach to your bill. ===Web Promotions=====Press Releases=====Link Exchanges========= Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Ph: 914-278-4933 Fx: 914-278-4507 E-mail: owlseye(a)owlsnest.com

1 0

World Time Zone Map
by Chuck Ellis May 10, 1997

May 10, 1997

I am re-sending this message in the absence of any indication it was received the first time it was sent. -Chuck Ellis Gentlemen: I have completed a Beta of a 1:1,000,000-scale world vector map of time zones and associated attribute data, including applicable Rule, ISO Country Codes, etc. In reviewing the tz archive postings, it became clear that some of you are working towards the same end. Therefore, I am posting the Beta to our company's FTP site in the hope that we can join forces to accelerate the development of this most useful map and data set. Background: I am a partner in MaconUSA, LLC, a digital mapping company based in Boston whose chief products are digital vector maps (with attached attribute data) of the world's political, administrative, civil, postal and telcomm boundaries. MaconUSA is the US "sister" company to Macon GmbH (Waghausel, Germany), which manufactures a suite of desktop mapping products for the European market. While we distribute primarily into the GIS market, our maps are for the most part focused on demographic, sales and marketing applications. We have developed comprehensive boundary and features sets for Europe and the US, and are in the process of completing a Mexican/Caribbean/Central American/South American Map set. We are Data Partners to virtually all of the major GIS application companies, such as ESRI, MapInfo, AutoDesk, Tactician, et al; our European maps are a (new) free inclusion in all of ESRI's shipping products. We have fielded numerous requests over the past year from our customers for both an accurate/current worldwide time zone map, and an equivalent map delineating telephone country and area code boundaries; the time zone map is the completion of part one of this development effort. While we are obviously a for-profit company, we are interested in a cooperative and public-interest effort regarding the time zone map. I would envision such cooperation including joint posting/maintenance of a time zone-map web page freely accessible to the worldwide public, participation in ongoing standards-oriented work (such as it is or may become), etc. The TZ archives maintained at elsie.nci.nih.gov appear to be as close to a defacto standards repository as a non-authoritative listserv can be; in the absence of any greater authority, we would prefer to work actively with it. Time zone Map: Three compressed files are posted at ftp://maconusa.com -- time zone.zip timezon2.zip time zone3.zip The first file (time zone.zip) contains time zone.* (the primary time zone vector map and its attached attribute database); a rough readme.txt file for overview; tz_struc.txt which describes the attribute database in detail; city_550.* (the "top" 550 cities in the world as map points with tz atributes); mid_mif.txt (which is a detailed description of MapInfo's ASCII vector map-file format that all boundary, point, and other map layers are written to, and is enough of a lingua franca to be transportable across many GIS and CAD applications). The second file (timezon2.zip) contains city_11k.* (a gazetteer of the "top" 11,000 cities in the world as map points with tz atributes); airport.* (a second gazetteer of 14,000+ airports worldwide as map points with tz attributes); ports.* (a third gazetteer of 4,500+ Ports around the world plotted as map points with tz attributes); overlay.* (a simple grid of the old 1884 GMT time zone lines for reference viewing; and ????struc.txt files detailing the file layouts for the gazetteer attribute databases. The third file (timezon3.zip) contains city_80k.* (a massive gazetteer of 80,000 cities around the world plotted as map points with associated tz attributes). All three files are password protected. The password is: proeger The files have been zipped with pkzip v. 2.04g Map Description: The map is based upon Macon's own ISO-3166 standard world map, a commercial product that is updated semi-annually. In turn, Macon's world map is based upon the original 1:1,000,000 DCW with a significant number of boundaries redrawn and/or updated to reflect current ISO-3166 definitions. The Datum is WGS1984; this particular map is current to December 31, 1996. The map was created in MapInfo, and has not yet been cleaned/processed with ArcInfo into a topological coverage (this will happen soon); the polygons are drawn in an essentially connect-the-dots sequence with preliminary shared-border snapping and de-duping. Please refer to the mid_mif.txt file for a detailed description of MapInfo's ASCII vector format. The 34 unique UTC-Offsets have been assigned colors according to a west-to-east spectral graduation using the Netscape 256-color chart (which is also Windows-compliant); these can be ignored or changed at will. The gazetteer points are derived from different sources. A significant number of just-onshore points appear slightly offshore due to being digitized from lower-scale maps and/or different datums; these have been properly attributed with tz data, but will be positionally adjusted in the final release. Nevertheless, the gazetteer collection has been included at this time because it is powerful testament to the primary advantage of defining detailed time zone polygons: a simple point-in-polygon operation can in one pass assign tz attributes to a virtually limitless number of map objects. Specific Time zone Notes: We have had to take some liberties in this beta version: 1) Asia/Timor -- A specific objective in producing this file was maintenance of strict ISO-3166 compliance; in this case, the principal requirement was simply including every country in the ISO roster. To wit, we added a new time zone, Asia/Timor, to represent East Timor. It has been assigned the (default) rule, No_DST, which matches its neighboring zone, Asia/Ujung_Pandang. 2) Atlantic/Madeira -- Even though Atlantic/Madeira is a duplicate of Europe/Lisbon, it was left as a distinct zone for cartographic purposes; linking far-flung polygons into one object can cause problems in many mapping applications when, for example, centroids are calculated, labels are auto-placed, or MBR (minimum-bounding-rectangle) calculations are involved. 3) America/Dawson_Creek -- this boundary is approximate only, due to a lack of any refining information. 4) America/Regina, America/Winnipeg -- these boundaries obey all available notes from the archives, but are simply invented using provincial sub-boundaries and meridians/parallels in the absence of any meaningful feature definitions 5) America/Scoresbysund -- this boundary is approximate only, albeit probably very close 6) America/Thule -- same as (4) above 7) Asia/Aqtau, Asia/Aqtobe, Asia/Alma-Ata -- these boundaries were created using current provincial sub-boundaries in the absence of any refining data 8) Africa/Kinshasha, Africa/Lubumbashi -- same as (7) above 9) Asia/Irkutsk, Asia/Yakutsk, Asia/Vladivostok, Asia/Magadan -- the boundaries between these zones are not well-defined; we used a CIA map from 1994 at a scale of 1:5,000,000 to approximate these 10) America/Manaus, America/Fortaleza -- we defaulted the split between these two zones as a simple east-west meridian dividing Para 11) The attached tz attribute database defaults the ending year for currently-active Rules to 1999 for now to ease the burden on application developers using the data; this is obviously quite artificial, and any suggestions for how to handle this would be appreciated 12) The default Rule for countries with no active DST assignations is "No_DST" 13) Historical Zone and Rule information is for the most part not included; only in the case of a current Zone using a current Rule with a (provided) onset-date was the start-year included; we are happy to change this based on agreed-upon suggestions, but the drawing of historical zones is well beyond our scope. Viewing the Time zone Map: We apologize for not providing the tz map in a directly-viewable format just yet. We are currently embedding the map with its associated database into an applet which I will upload in the coming weeks. Those wishing to view the map at this time have the following alternatives: a) Use MapInfo-- both the MapInfo Desktop and MapInfo Professional products can import mid-mif files directly, since it is the intermediate ASCII format for both applications b) Use ArcView, BusinessMap, ArcInfo, or ArcCAD-- all ESRI products can import mid-mif files directly c) Use Microsoft Excel Version 7 or higher, or Microsoft Office95 or higher-- these newer versions of Excel contain a feature called DataMap which can draw, color and query a MapInfo-BINARY format map directly; I will be posting the time zone map in this format in the next day or so as timezon4.zip at ftp://www.maconusa.com d) Use Any CAD Software-- I will be posting a .DXF version of the map in the next day or so as timezon5.zip at ftp://maconusa.com e) Write Your Own Viewer-- the mid-mif ASCII vector map format is quite simple, though with all of the applications out there capable of directly handling mid-mif, you're probably better off waiting for the Excel or CAD versions to post in the next day or so, or our own embedded viewer to post within the next couple of weeks. Continued Development: We are quite committed to upgrading, updating, and generally improving this map. Any specific zone comments relating to how/where the boundaries are drawn are most useful if they provide or describe (in order of preference): the actual map, or a reference to where we can find it; underlying sub-boundaries (such as administrative or statistical or poitical or postal or municipal) comprising the zone; major land or water features which delineate a boundary or part of boundary; a "legal" description (such as "follow rickety river six miles south, then east along provincial boundary..."); corrections/additions/deletions to the list of cities/towns included in a zone (you may find the gazetteer of 80,000 cities posted as noted above useful as a starter here). Comments or Questions: Please contact Chuck Ellis, at MaconUSA, 214 Lincoln Street, Suite 115, Allston, MA 02134, Tel 617-254-2295, Fax 617-254-2883, e-mail chuck_ellis(a)msn.com. Respects, Chuck Ellis VP, R&D MaconUSA, LLC

1 0

ISO 3166 and the "tz" Database
by Dave Skinner May 10, 1997

May 10, 1997

First of all, in case you were not aware of the fact, 3 of the 238 different ISO 3166 "countries" listed in file "tzdata/iso3166.tab" have no corresponding zone in the "tz" database. They are BV Bouvet Island HM Heard Island & McDonald Islands TP East Timor Bouvet Island is described in file "tzdata/antarctica" as # Norway - territories # Bouvet (uninhabited) Heard Island & McDonald Islands is described in file "tzdata/antarctica" as # Australia - territories # Heard Island, McDonald Islands No other information about Heard Island & McDonald Islands is provided. As for "East Timor", it is an area that both Indonesia and Portugal claim sovereignty over which is not recognized by the United Nations, or so says the 1996 edition of the CIA World Factbook. I can find no reference to "Timor", let alone "East Timor", in any of the "tzdata/*" files except, of course, "tzdata/iso3166.tab". Next, if the "tz" database is REALLY going to adhere to ISO 3166, then the definitions of the various zones should be grouped by the "countries" defined therein. Currently, this is not the case. The following is a complete list of the ISO 3166 countries that have multiple zone entries in the "tz" database. AQ Antarctica AR Argentina AU Australia BR Brazil CA Canada CL Chile CN China EC Ecuador ES Spain FM Micronesia GB Britain (UK) GL Greenland ID Indonesia IL Israel JP Japan KI Kiribati KZ Kazakhstan MH Marshall Islands ML Mali MX Mexico MY Malaysia NZ New Zealand PF French Polynesia PT Portugal RU Russia SJ Svalbard & Jan Mayen UA Ukraine UM US minor outlying islands US United States ZR Zaire There are 30 of them. As reported in my most recent previous email, 23 of these "countries" currently have multiple internal time zones, i.e. multiple areas that differ in how and when they observe the time that they do, but that is irrelevent here. By inspection, I found that the country groupings in the following five continent files tzdata/antarctica tzdata/asia tzdata/australasia tzdata/europe tzdata/northamerica do not, in general, follow the ISO 3166 groupings identified in file "tzdata/zone.tab" from which the above list was extracted. In particular, the following differences have been identified. AQ Antarctica Zone Indian/Kerguelen, that is defined in file "tzdata/antarctica" as part of the Antarctica definitions therein, is part of the "country" identified by the 2-letter country code "TF" for "French Southern & Antarctic Lands" with respect to ISO 3166, which does not appear in the above list. CN China China is identified as the "People's Republic of China" in file "tzdata/asia". This compares to just "China" with respect to ISO 3166. GB Britain (UK) Great Britain is identified as "United Kingdom" in file "tzdata/europe". This compares to "Britain (UK)" with respect to ISO 3166. Zone Europe/Dublin, that is defined in file "tzdata/europe" as part of the so-called "United Kingdom" definitions therein, is part if the country identified by the 2-letter country code "IE" for "Ireland" with respect to ISO 3166, which does not appear in the above list. GL Greenland Zones America/Thule, America/Godthab, and America/Scoresbysund, that are defined in file "tzdata/europe" as part of the Denmark definitions therein, are part of the "country" identified by the 2-letter country code "GL" for "Greenland" with respect to ISO 3166. Zone Atlantic/Faeroe, that is defined in file "tzdata/europe" as part of the Denmark definitions therein, is part of the "country" identified by the 2-letter country code "FO" for "Faeroe Islands" with respect to ISO 3166, which does not appear in the above list. Zone Europe/Copenhagen, that is defined in file "tzdata/europe" as part of the Denmark definitions therein, is part of the country of "Denmark" with its 2-letter country code "DK", with respect to ISO 3166, which does not appear in the above list. IL Israel Zone Asia/Gaza is defined in file "tzdata/asia" as part of a separate set of definitions for "Palestine" therein instead of as part of the corresponding Israel definitions. Yet, Asia/Gaza is part of the country identified by the 2-letter country code "IL" for "Israel" with respect to ISO 3166. SJ Svalbard & Jan Mayen Zone Atlantic/Jan_Mayen, that is defined in file "tzdata/europe" as part of the Norway definitions therein, is part of the "country" identified by the 2-letter country code "SJ" for "Svalbard & Jan Mayen" with respect to ISO 3166. Zone Arctic/Longyearbyen, that is linked to Europe/Oslo in file "tzdata/europe" as part of the Norway definitions therein, is part of the "country" identified by the 2-letter country code "SJ" for "Svalbard & Jan Mayen" with respect to ISO 3166. Zone Europe/Oslo, that is defined in file "tzdata/europe" as part of the Norway definitions therein, is part of the country of Norway with its 2-letter country code "NO" with respect to ISO 3166, which does not appear in the above list. UM US minor outlying islands Zones Pacific/Johnston and Pacific/Wake are individually defined in file "tzdata/australasia" instead of being grouped together under a set of definitions labeled "US Minor Outlying Islands", as would be expected by being part of the "country" identified by the 2-letter country code "UM" for "US minor outlying islands" with respect to ISO 3166. Zone Pacific/Midway is defined in file "tzdata/northamerica" as part of the United States definitions therein instead of in file "tzdata/australasia" along with zones Pacific/Johnston and Pacific/Wake as part of a set of definitions labeled "US Minor Outlying Islands" as would be indicated by being part of the country identified by the 2-letter country code "UM" for "US minor outlying islands" with respect to ISO 3166. KP Korea (North) and KR Korea (South) Zones Asia/Pyongyang and Asia/Seoul are defined in file "tzdata/asia" as part of the "Korea" definitions therein, but there should be separate sets of Korea (North) definitions, which would include zone Asia/Pyongyang, and Korea (South) definitions, which would include zone Asia/Seoul. This is what separate 2-letter country codes "KP" for "Korea (North)" and "KR" for "Korea (South)" indicate with respect to ISO 3166. Dave Skinner dave(a)kirdu.jpl.nasa.gov

1 0

Re: Daylight Extra and UK General Election
by peter＠aldie.co.uk May 9, 1997

May 9, 1997

Chris Carrier <72157.3334(a)CompuServe.COM> wrote: > As most of you know, on May 1 the United Kingdom had a General Election for > Parliament and Labor got in with a substantial majority. Chris, I'm surprised. I wouldn't have thought you would have missed a detail like this. It is the Labour Party, currently trading under the brand name New Labour. :-) > The results of one race might be interesting to some of us: the seat held by > John Butterfill (Con., Bournemouth West). Butterfill in 1995 introduced a > bill, known as the Daylight Extra Bill, which would have put the UK on summer > time in winter and double summer time in summer, to synchronise it with the > rest of the EU. There was an attempt to force it out of committee; this > requires the assent of 100 MPs (out of, I believe, a total number of 630) and > the Bill received the support of 93. What actually happened was there were insufficient MPs to force a vote on closing the debate, so a vote could be taken on the Bill itself. Only 93 were present, so presumably the debate rambled on without coming to any conclusion. This was at the stage called second reading, which is before the Bill would have been considered in detail by a committee of MPs. There were 650 MPs in the old Parliament, 659 in the new one. The fact that only 93 were present out of 650 was not particularly suprising. There aren't actually enough seats for all of them anyway. > What I would like to ask is if anyone saw anything concerning Daylight Extra > during the General Election as a whole or in Bournemouth West specifically. Much as we might wish it otherwise, discussion of the policies relating to time of any of the major parties was notable only by its complete absence. A `grep -i time' through the manifesto text of each of the three major parties (Labour, Conservative, Liberal Democrat) finds nothing relevent at all. A search though The Times between 1 March 97 and 30 April 97 for `daylight extra' also shows no hits. I didn't read all the election coverage in the papers I read but I didn't spot anything; neither did I hear anything on radio news. I admit I am a long way from Bournmouth, but I doubt it was much different down there. People here may get worked up about proposed changes to Summer Time arrangements and changes of timezone when a specific proposal appears but otherwise it really isn't an issue at all. Peter Ilieve peter(a)aldie.co.uk

1 0

Daylight Extra and UK General Election
by Chris Carrier May 9, 1997

May 9, 1997

As most of you know, on May 1 the United Kingdom had a General Election for Parliament and Labor got in with a substantial majority. The results of one race might be interesting to some of us: the seat held by John Butterfill (Con., Bournemouth West). Butterfill in 1995 introduced a bill, known as the Daylight Extra Bill, which would have put the UK on summer time in winter and double summer time in summer, to synchronise it with the rest of the EU. There was an attempt to force it out of committee; this requires the assent of 100 MPs (out of, I believe, a total number of 630) and the Bill received the support of 93. (Note to anyone: I would appreciate clarification/correction to any of this.) I was able to get the results of Bournemouth West last weekend, and Butterfill managed to retain his seat, but he lost 14 percentage points, which was comparable to the Conservative loss of support in the rest of the UK, so his sponsorship of Daylight Extra didn't seem to either help or hurt him. What I would like to ask is if anyone saw anything concerning Daylight Extra during the General Election as a whole or in Bournemouth West specifically. Chris Carrier

1 0

Re: World Timezone Map
by Dave Skinner May 9, 1997

May 9, 1997

I was ever so glad to receive the recent email fro Chuck Ellis of MaconUSA, LLC. I have been busy behind the scenes collecting and organizing the boundary data for the time zone map capability previously discussed in the tz archive at elsie.nci.nih.gov. This was without the knowledge of, or data from, maconusa.com. I wanted to respond to Chuck Ellis' email in a timely fashion, and in lieu of what I read in that email, I wanted to introduce my internal time zone boundary numbering scheme for the current set of countries with multiple internal time zones that I have been working on to facilitate discussion of the status and accuracy of the boundary data associated with these key otherwise missing boundaries. Following up on the ISO-3166 work already done with respect to the Time Zone Database (tz), I organized my efforts around that standard as well. So, high level compatibility with maconusa.com should already be achieved. Likewise, I gathered the 1:1,000,000 scale Digital Chart of the World (DCW) data and augmented it with 1:100,000 USGS state and county data from the 1990 census. I realized that many of the poltical boundaries had changed since 1992, when the version of DCW to which I obtained access was released. I was hoping to update that with the Vector Smart Map Level 0 (VMap0) data once I could get my hands on it. I was also prepared to work backward from the .pdf map files that are posted by the CIA as part of their web page providing access to "The World Factbook 1996", as a last resort. There is an actual a time zone map of the world published there as well, for what it is worth. This web page is located at or near http://www.odci.gov/cia/publications/nsolo/wfb-all.htm AS Chuck Ellis' email arrived, I still did not have accurate data for, or descriptions of, the time zone boundaries inside of countries with multiple time zones, although boundaries 05.01, 06.01, 07.01, 15.01, and 17.01 in the attached table may simply be the distinction between the mainland and the island(s) in question. As for viewing map data, I acquired a copy of GRASS and Grassland (a beta copy for SunOS5 from LAS, Inc. of Canada of the latter) which permit the viewing of VPF (DCW, VMap0) and SDTS (USGS) file formats. I am really new at all of this. So, exactly how to proceed to take any of the various .zip files at maconusa.com and to make use of these Unix-based viewers would be appreciated. (I would prefer to stay Unix-based, if that is at all possible.) The goal, as Chuck Ellis observed, should most definitely be to create a set of time zone polygons, because the ability to automatically update the gazetteer whenever a change is introduced is straightforward, simple, and an already solved problem with already written available code. Anyhow, here is the ISO-3166 sorted list of internal time zone boundaries to which I have been alluding. Of the 30 ISO-3166 "countries" with multiple zones in the tz database, there are only 23 which currently have multiple time zones. These 23 countries have 69 internal boundaries by my current tally. As we are all aware, multiple time zones include the distinction between the boundaries when Daylight Savings Time is in effect, e.g. the distinction between the U.S. Eastern Time Zone with and without that portion of Indiana that does not observe daylight savings time attached in the standard time October-to-April period (boundary 22.07) and in the daylight time April-to-October period (boundary 22.08), respectively, of any given year. Note that Antarctica and Greenland boundaries isolate the tz zones in question from the rest of the land mass, as opposed to separating a series of mostly vertical strips from each other like the boundaries of the other 21 ISO-3166 "countries" listed below. Dave Skinner dave(a)kirdu.jpl.nasa.gov 818-354-0114 (voice) 818-393-9900 (fax) --------------------------------------------------------------------------- 01. AQ Antarctica ------------------------------------------------------------- 01.01 |Antarctica/Palmer --4:00 ChileAQ -------------------------------------------------------------| ------------------------------------------------------------- 01.02 |Antarctica/Mawson +6:00 None -------------------------------------------------------------| ------------------------------------------------------------- 01.03 |Antarctica/Casey +8:00 None -------------------------------------------------------------| ------------------------------------------------------------- 01.04 |Antarctica/DumontDUrville +10:00 None -------------------------------------------------------------| ------------------------------------------------------------- 01.05 |Antarctica/McMurdo +12:00 NZAQ -------------------------------------------------------------| 02. AU Australia Indian/Christmas +7:00 None ------------------------------------------------------------- 02.01 Australia, Western Australia/Perth +8:00 None ------------------------------------------------------------- 02.02 Australia, Central Australia/Adelaide +9:30 AS ----------------------------------------------------- 02.03 Australia/Darwin +9:30 Aus --> None ------------------------------------------------------------- 02.04 Australia, Eastern Australia/Brisbane +10:00 AQ --> None ----------------------------------------------------- 02.05 Australia/Hobart +10:00 AT ----------------------------------------------------- 02.06 Australia/Sydney +10:00 AN ------------------------------------------------------------- 02.07 Australia/Lord_Howe +10:30 LH 03. BR Brazil America/Porto_Acre --5:00 None ------------------------------------------------------------- 03.01 Brazil, Western America/Cuiaba --4:00 Brazil ----------------------------------------------------- 03.02 America/Manaus --4:00 None ------------------------------------------------------------- 03.03 Brazil, Eastern America/Fortaleza --3:00 None ----------------------------------------------------- 03.04 America/Sao_Paulo --3:00 Brazil ------------------------------------------------------------- 03.05 America/Noronha --2:00 None 04. CA Canada Canada, Pacific America/Vancouver --8:00 Vanc ------------------------------------------------------------- 04.01 Canada, Mountain America/Dawson_Creek --7:00 None ----------------------------------------------------- 04.02 America/Edmonton --7:00 Edm ------------------------------------------------------------- 04.03 Canada, Central America/Regina --6:00 None ----------------------------------------------------- 04.04 America/Winnipeg --6:00 Winn ------------------------------------------------------------- 04.05 Canada, Eastern America/Montreal --5:00 Mont ------------------------------------------------------------- 04.06 Canada, Atlantic America/Halifax --4:00 Halifax ------------------------------------------------------------- 04.07 Canada, Newfoundland America/St_Johns --3:30 StJohns 05. CL Chile Pacific/Easter --6:00 Chile ------------------------------------------------------------- 05.01 America/Santiago --4:00 Chile 06. EC Ecuador Pacific/Galapagos --6:00 None ------------------------------------------------------------- 06.01 America/Guayaquil --5:00 None 07. ES Spain Atlantic/Canary +0:00 EU ------------------------------------------------------------- 07.01 Europe/Madrid +1:00 EU 08. FM Micronesia Pacific/Yap +10:00 None ------------------------------------------------------------- 08.01 Pacific/Ponape (Pohnpei) +11:00 None ------------------------------------------------------------- 08.02 Pacific/Kosrae +12:00 None 09. GL Greenland ------------------------------------------------------------- 09.01 |America/Thule --4:00 Thule -------------------------------------------------------------| ------------------------------------------------------------- 09.02 |America/Godthab (Nuuk) --3:00 EU -------------------------------------------------------------| ------------------------------------------------------------- 09.03 |America/Scoresbysund (Ittoqqortoormiit) --1:00 EU -------------------------------------------------------------| 10. ID Indonesia Asia/Jakarta +7:00 None ------------------------------------------------------------- 10.01 Asia/Ujung_Pandang +8:00 None ------------------------------------------------------------- 10.02 Asia/Jayapura +9:00 None 11. JP Japan Asia/Ishigaki +8:00 None ------------------------------------------------------------- 11.01 Asia/Tokyo +9:00 None 12. KI Kiribati Pacific/Tarawa +12:00 None ------------------------------------------------------------- 12.01 Pacific/Enderbury +13:00 None ------------------------------------------------------------- 12.02 Pacific/Kiritimati +14:00 None 13. KZ Kazakhstan Asia/Aqtau +4:00 E--Eur ------------------------------------------------------------- 13.01 Asia/Aqtobe +5:00 E--Eur ------------------------------------------------------------- 13.02 Asia/Alma--Ata +6:00 E-Eur 14. MX Mexico Mexico, Pacific America/Tijuana --8:00 Mexico ------------------------------------------------------------- 14.01 Mexico, Mountain America/Mazatlan --7:00 Mexico ------------------------------------------------------------- 14.02 Mexico, Central America/Mexico_City --6:00 Mexico 15. NZ New_Zealand Pacific/Auckland +12:00 NZ ------------------------------------------------------------- 15.01 Pacific/Chatham +12:45 Chatham 16. PF French_Polynesia Pacific/Tahiti --10:00 None ------------------------------------------------------------- 16.01 Pacific/Marquesas --9:30 None ------------------------------------------------------------- 16.02 Pacific/Gambier --9:00 None 17. PT Portugal Atlantic/Azores --1:00 EU ------------------------------------------------------------- 17.01 Europe/Lisbon +0:00 EU 18. RU Russia Europe/Kaliningrad +2:00 Russia ------------------------------------------------------------- 18.01 Europe/Moscow +3:00 Russia ------------------------------------------------------------- 18.02 Europe/Samara +4:00 Russia ------------------------------------------------------------- 18.03 Europe/Yekaterinburg +5:00 Russia ------------------------------------------------------------- 18.04 Asia/Novosibirsk +6:00 Russia ------------------------------------------------------------- 18.05 Asia/Krasnoyarsk +7:00 Russia ------------------------------------------------------------- 18.06 Asia/Irkutsk +8:00 Russia ------------------------------------------------------------- 18.07 Asia/Yakutsk +9:00 Russia ------------------------------------------------------------- 18.08 Asia/Vladivostok +10:00 Russia ------------------------------------------------------------- 18.09 Asia/Magadan +11:00 Russia ------------------------------------------------------------- 18.10 Asia/Kamchatka +12:00 Russia ------------------------------------------------------------- 18.11 Asia/Anadyr +13:00 Russia 19. SJ Svalbard_&_Jan_Mayen Atlantic/Jan_Mayen (Svalbard) --1:00 None ------------------------------------------------------------- 19.01 Arctic/Longyearbyen +1:00 EU 20. UA Ukraine Europe/Kiev +2:00 EU ------------------------------------------------------------- 20.01 Europe/Simferopol +3:00 Crimea 21. UM US_minor_outlying_islands Pacific/Midway --11:00 None ------------------------------------------------------------- 21.01 United_States, Samoa Pacific/Johnston --10:00 None ------------------------------------------------------------- 21.02 Pacific/Wake +12:00 None 22. US United_States United_States, Hawaii--Aleutian America/Adak --10:00 US ----------------------------------------------------- 22.01 Pacific/Honolulu --10:00 None ------------------------------------------------------------- 22.02 United_States, Alaska America/Anchorage --9:00 US ------------------------------------------------------------- 22.03 United_States, Pacific America/Los_Angeles --8:00 US ------------------------------------------------------------- 22.04 United_States, Mountain America/Denver --7:00 US ----------------------------------------------------- 22.05 America/Phoenix --7:00 None ------------------------------------------------------------- 22.06 United_States, Central America/Chicago --6:00 US ------------------------------------------------------------- 22.07 United_States, Eastern America/Indianapolis --5:00 None ----------------------------------------------------- 22.08 America/New_York --5:00 US 23. ZR Zaire Africa/Kinshasa +1:00 None ------------------------------------------------------------- 23.01 Africa/Lubumbashi +2:00 None

1 0

World Timezone Map
by Chuck Ellis May 8, 1997

May 8, 1997

Gentlemen: I have completed a Beta of a 1:1,000,000-scale world vector map of timezones and associated attribute data, including applicable Rule, ISO Country Codes, etc. In reviewing the tz archive postings, it became clear that some of you are working towards the same end. Therefore, I am posting the Beta to our company's FTP site in the hope that we can join forces to accelerate the development of this most useful map and data set. Background: I am a partner in MaconUSA, LLC, a digital mapping company based in Boston whose chief products are digital vector maps (with attached attribute data) of the world's political, administrative, civil, postal and telcomm boundaries. MaconUSA is the US "sister" company to Macon GmbH (Waghausel, Germany), which manufactures a suite of desktop mapping products for the European market. While we distribute primarily into the GIS market, our maps are for the most part focused on demographic, sales and marketing applications. We have developed comprehensive boundary and features sets for Europe and the US, and are in the process of completing a Mexican/Caribbean/Central American/South American Map set. We are Data Partners to virtually all of the major GIS application companies, such as ESRI, MapInfo, AutoDesk, Tactician, et al; our European maps are a (new) free inclusion in all of ESRI's shipping products. We have fielded numerous requests over the past year from our customers for both an accurate/current worldwide timezone map, and an equivalent map delineating telephone country and area code boundaries; the timezone map is the completion of part one of this development effort. While we are obviously a for-profit company, we are interested in a cooperative and public-interest effort regarding the timezone map. I would envision such cooperation including joint posting/maintenance of a timezone-map web page freely accessible to the worldwide public, participation in ongoing standards-oriented work (such as it is or may become), etc. The TZ archives maintained at elsie.nci.nih.gov appear to be as close to a defacto standards repository as a non-authoritative listserv can be; in the absence of any greater authority, we would prefer to work actively with it. Timezone Map: Three compressed files are posted at ftp://maconusa.com -- timezone.zip timezon2.zip timezone3.zip The first file (timezone.zip) contains timezone.* (the primary timezone vector map and its attached attribute database); a rough readme.txt file for overview; tz_struc.txt which describes the attribute database in detail; city_550.* (the "top" 550 cities in the world as map points with tz atributes); mid_mif.txt (which is a detailed description of MapInfo's ASCII vector map-file format that all boundary, point, and other map layers are written to, and is enough of a lingua franca to be transportable across many GIS and CAD applications). The second file (timezon2.zip) contains city_11k.* (a gazetteer of the "top" 11,000 cities in the world as map points with tz atributes); airport.* (a second gazetteer of 14,000+ airports worldwide as map points with tz attributes); ports.* (a third gazetteer of 4,500+ Ports around the world plotted as map points with tz attributes); overlay.* (a simple grid of the old 1884 GMT timezone lines for reference viewing; and ????struc.txt files detailing the file layouts for the gazetteer attribute databases. The third file (timezon3.zip) contains city_80k.* (a massive gazetteer of 80,000 cities around the world plotted as map points with associated tz attributes). All three files are password protected. The password is: proeger The files have been zipped with pkzip v. 2.04g Map Description: The map is based upon Macon's own ISO-3166 standard world map, a commercial product that is updated semi-annually. In turn, Macon's world map is based upon the original 1:1,000,000 DCW with a significant number of boundaries redrawn and/or updated to reflect current ISO-3166 definitions. The Datum is WGS1984; this particular map is current to December 31, 1996. The map was created in MapInfo, and has not yet been cleaned/processed with ArcInfo into a topological coverage (this will happen soon); the polygons are drawn in an essentially connect-the-dots sequence with preliminary shared-border snapping and de-duping. Please refer to the mid_mif.txt file for a detailed description of MapInfo's ASCII vector format. The 34 unique UTC-Offsets have been assigned colors according to a west-to-east spectral graduation using the Netscape 256-color chart (which is also Windows-compliant); these can be ignored or changed at will. The gazetteer points are derived from different sources. A significant number of just-onshore points appear slightly offshore due to being digitized from lower-scale maps and/or different datums; these have been properly attributed with tz data, but will be positionally adjusted in the final release. Nevertheless, the gazetteer collection has been included at this time because it is powerful testament to the primary advantage of defining detailed timezone polygons: a simple point-in-polygon operation can in one pass assign tz attributes to a virtually limitless number of map objects. Specific Timezone Notes: We have had to take some liberties in this beta version: 1) Asia/Timor -- A specific objective in producing this file was maintenance of strict ISO-3166 compliance; in this case, the principal requirement was simply including every country in the ISO roster. To wit, we added a new timezone, Asia/Timor, to represent East Timor. It has been assigned the (default) rule, No_DST, which matches its neighboring zone, Asia/Ujung_Pandang. 2) Atlantic/Madeira -- Even though Atlantic/Madeira is a duplicate of Europe/Lisbon, it was left as a distinct zone for cartographic purposes; linking far-flung polygons into one object can cause problems in many mapping applications when, for example, centroids are calculated, labels are auto-placed, or MBR (minimum-bounding-rectangle) calculations are involved. 3) America/Dawson_Creek -- this boundary is approximate only, due to a lack of any refining information. 4) America/Regina, America/Winnipeg -- these boundaries obey all available notes from the archives, but are simply invented using provincial sub-boundaries and meridians/parallels in the absence of any meaningful feature definitions 5) America/Scoresbysund -- this boundary is approximate only, albeit probably very close 6) America/Thule -- same as (4) above 7) Asia/Aqtau, Asia/Aqtobe, Asia/Alma-Ata -- these boundaries were created using current provincial sub-boundaries in the absence of any refining data 8) Africa/Kinshasha, Africa/Lubumbashi -- same as (7) above 9) Asia/Irkutsk, Asia/Yakutsk, Asia/Vladivostok, Asia/Magadan -- the boundaries between these zones are not well-defined; we used a CIA map from 1994 at a scale of 1:5,000,000 to approximate these 10) America/Manaus, America/Fortaleza -- we defaulted the split between these two zones as a simple east-west meridian dividing Para 11) The attached tz attribute database defaults the ending year for currently-active Rules to 1999 for now to ease the burden on application developers using the data; this is obviously quite artificial, and any suggestions for how to handle this would be appreciated 12) The default Rule for countries with no active DST assignations is "No_DST" 13) Historical Zone and Rule information is for the most part not included; only in the case of a current Zone using a current Rule with a (provided) onset-date was the start-year included; we are happy to change this based on agreed-upon suggestions, but the drawing of historical zones is well beyond our scope. Viewing the Timezone Map: We apologize for not providing the tz map in a directly-viewable format just yet. We are currently embedding the map with its associated database into an applet which I will upload in the coming weeks. Those wishing to view the map at this time have the following alternatives: a) Use MapInfo-- both the MapInfo Desktop and MapInfo Professional products can import mid-mif files directly, since it is the intermediate ASCII format for both applications b) Use ArcView, BusinessMap, ArcInfo, or ArcCAD-- all ESRI products can import mid-mif files directly c) Use Microsoft Excel Version 7 or higher, or Microsoft Office95 or higher-- these newer versions of Excel contain a feature called DataMap which can draw, color and query a MapInfo-BINARY format map directly; I will be posting the timezone map in this format in the next day or so as timezon4.zip at ftp://www.maconusa.com d) Use Any CAD Software-- I will be posting a .DXF version of the map in the next day or so as timezon5.zip at ftp://maconusa.com e) Write Your Own Viewer-- the mid-mif ASCII vector map format is quite simple, though with all of the applications out there capable of directly handling mid-mif, you're probably better off waiting for the Excel or CAD versions to post in the next day or so, or our own embedded viewer to post within the next couple of weeks. Continued Development: We are quite committed to upgrading, updating, and generally improving this map. Any specific zone comments relating to how/where the boundaries are drawn are most useful if they provide or describe (in order of preference): the actual map, or a reference to where we can find it; underlying sub-boundaries (such as administrative or statistical or poitical or postal or municipal) comprising the zone; major land or water features which delineate a boundary or part of boundary; a "legal" description (such as "follow rickety river six miles south, then east along provincial boundary..."); corrections/additions/deletions to the list of cities/towns included in a zone (you may find the gazetteer of 80,000 cities posted as noted above useful as a starter here). Comments or Questions: Please contact Chuck Ellis, at MaconUSA, 214 Lincoln Street, Suite 115, Allston, MA 02134, Tel 617-254-2295, Fax 617-254-2883, e-mail chuck_ellis(a)msn.com. Respects, Chuck Ellis VP, R&D MaconUSA, LLC

1 0

new versions of tzcode and tzdata
by ado May 3, 1997

May 3, 1997

The files ftp://elsie.nci.nih.gov/pub/tzcode1997e.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1997f.tar.gz are now available. These incorporate the fixes to zic's error handling that were recently circulated on the tz list, as well as changes inspired by the item circulated on Slovenia. The description of Web resources has been htmlified for browsing convenience, and a new piece of tz-related music has been added to the "Music" file. --ado

1 0

-v option support
by tpm＠hi.com May 1, 1997

May 1, 1997

The zic(8) man page describes the -v option as -v Complain if a year that appears in a data file is out- side the range of years representable by time(2) values. However this functionality appears to have been removed from the code. It is not clear whether this description should have been removed from the man page or whether the functionality was unintentionally removed from the code. If the general consensus is that the man page is correct then some code similar to the following could be added to implement it. I am open to issues and alternatives. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *************** *** 129,134 **** --- 263,269 ---- static void usage P((void)); static void writezone P((const char * name)); static int yearistype P((int year, const char * type)); + static void year_noise_check P((int year)); #if !(HAVE_STRERROR - 0) static char * strerror P((int)); *************** *** 141,148 **** --- 276,285 ---- static int linenum; static time_t max_time; static int max_year; + static int max_year_representable; static time_t min_time; static int min_year; + static int min_year_representable; static int noise; static const char * rfilename; static int rlinenum; *************** *** 649,654 **** --- 824,831 ---- } min_year = TM_YEAR_BASE + gmtime(&min_time)->tm_year; max_year = TM_YEAR_BASE + gmtime(&max_time)->tm_year; + min_year_representable = min_year; + max_year_representable = max_year; } *************** *** 1278,1288 **** rp->r_yrtype = NULL; else { if (rp->r_loyear == rp->r_hiyear) { ! error(_("typed single year")); return; } rp->r_yrtype = ecpyalloc(typep); } if (rp->r_loyear < min_year && rp->r_loyear > 0) min_year = rp->r_loyear; /* --- 1463,1478 ---- rp->r_yrtype = NULL; else { if (rp->r_loyear == rp->r_hiyear) { ! error(MSGSTR(ONEYEAR,"typed single year")); return; } rp->r_yrtype = ecpyalloc(typep); } + if (noise) + { + year_noise_check(rp->r_loyear); + year_noise_check(rp->r_hiyear); + } if (rp->r_loyear < min_year && rp->r_loyear > 0) min_year = rp->r_loyear; /* *************** *** 2169,2179 **** l = i; if ((i < 0 && l >= 0) || (i == 0 && l != 0) || (i > 0 && l <= 0)) { (void) fprintf(stderr, ! _("%s: %d did not sign extend correctly\n"), progname, i); (void) exit(EXIT_FAILURE); } return l; } /* --- 2365,2399 ---- l = i; if ((i < 0 && l >= 0) || (i == 0 && l != 0) || (i > 0 && l <= 0)) { (void) fprintf(stderr, ! MSGSTR(BADSIGN,"%s: %d did not sign extend correctly.\n"), progname, i); (void) exit(EXIT_FAILURE); } return l; + } + + static void + year_noise_check(year) + int year; + { + if ( ( (year < min_year_representable) || + (year > max_year_representable) ) && + ( (year != INT_MIN) && (year != INT_MAX) ) ) + { + static char *format; + static char *message; + + if (!format) + { + format = MSGSTR(UNREPYEAR, "unrepresentable year: %d"); + } + if (!message) + { + message = emalloc(strlen(format) + 32); + } + (void) sprintf(message, format, year); + warning(message); + } } /* <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Note that MSGSTR() is a simple macro that invokes catgets(3) on systems which support the X/Open interfaces. ---------------------------------------------------------------------- Timothy Patrick Murphy tpm(a)hi.com Voice: (617) 890-0444 Hitachi Computer Products Fax: (617) 890-4998 1601 Trapelo Rd., Waltham, MA 02154, USA ----------------------------------------------------------------------

1 0

warning string missing
by tpm＠hi.com May 1, 1997

May 1, 1997

The warning() function in zic.c contains the following code. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> static void warning(string) const char * const string; { char * cp; cp = ecpyalloc("warning: "); cp = ecatalloc(cp, string); error(string); ifree(cp); --errors; } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< It appears the argument to error() should be cp instead of string. -- ------ ---------------------------------------------------------------------- Timothy Patrick Murphy tpm(a)hi.com Voice: (617) 890-0444 Hitachi Computer Products Fax: (617) 890-4998 1601 Trapelo Rd., Waltham, MA 02154, USA ----------------------------------------------------------------------

1 0