February 2001 - tz - lists.iana.org

proposed tz change for Latvia, Lithuania
by Paul Eggert 25 May '15

25 May '15

It's March Madness time for daylight-saving rule changes. Here's a proposed change to the tz database to keep up with the latest political development, which affects time stamps starting March 29: * Latvia and Lithuania will not observe DST, starting this year. Thanks to Andrei Ivanov for this info. =================================================================== RCS file: RCS/europe,v retrieving revision 2000.3 retrieving revision 2000.3.0.1 diff -pu -r2000.3 -r2000.3.0.1 --- europe 2000/03/04 15:31:08 2000.3 +++ europe 2000/03/08 17:48:59 2000.3.0.1 @@ -1135,6 +1135,12 @@ Link Europe/Rome Europe/San_Marino # 1997-01-21 on transition to Summer time ... established the same order of # daylight savings time settings as in the States of the European Union. +# From Andrei Ivanov (2000-03-06): +# This year Latvia will not switch to Daylight Savings Time (as specified in +# <a href="http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm"> +# The Regulations of the Cabinet of Ministers of the Rep. of Latvia of +# 29-Feb-2000 (#79)</a>, in Latvian for subscribers only). + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Latvia 1989 1996 - Mar lastSun 2:00s 1:00 S Rule Latvia 1989 1996 - Sep lastSun 2:00s 0 - @@ -1151,7 +1157,8 @@ Zone Europe/Riga 1:36:24 - LMT 1880 3:00 Russia MSK/MSD 1989 Mar lastSun 2:00s 2:00 1:00 EEST 1989 Sep lastSun 2:00s 2:00 Latvia EE%sT 1997 Jan 21 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb 29 + 2:00 - EET # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1178,6 +1185,11 @@ Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun # motion to give up shifting to summer time in spring, as it was # already done by Estonia. +# From Andrei Ivanov (2000-03-06): +# I've heard that Ministers of three Baltic countries on their summit +# somewhere in February decided not to switch to summer time starting from +# this spring. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Vilnius 1:41:16 - LMT 1880 1:24:00 - WMT 1917 # Warsaw Mean Time @@ -1192,7 +1204,8 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 2:00 C-Eur EE%sT 1998 2:00 - EET 1998 Mar 29 1:00u 1:00 EU CE%sT 1999 Oct 31 1:00u - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb + 2:00 - EET # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks.

5 5

Html-ize the tz database?
by Gwillim Law 02 Mar '01

02 Mar '01

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

5 7

RE: Html-ize the tz database?
by Chuck Ellis 28 Feb '01

28 Feb '01

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) 27 Feb '01

27 Feb '01

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 27 Feb '01

27 Feb '01

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 23 Feb '01

23 Feb '01

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 20 Feb '01

20 Feb '01

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 19 Feb '01

19 Feb '01

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) 18 Feb '01

18 Feb '01

-----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 17 Feb '01

17 Feb '01

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