- tz - lists.iana.org

RE: Possible corrections?
by Phillip Guerra July 6, 2006

July 6, 2006

Just to clarify... I'm not advocating changing the format of the datastore. You notice I refer to it as a datastore, not a database, because to do so implies IMHO that it is structured with a unique database format, which of course it is not. Easy editing by humans is certainly the goal, what I suggested is merely avoiding the ambiguity assosiciated with some of the data, not the structure exactly. As I move more comfortably with using my new Linux test machine, I would probably agree that the zic output would be maybe a better choice for machine exchange, and my efforts would have taken less time if I had a system to use ZIC when I began. However, when the original parsing language and programms are not used with the native datastore, the TZINFO datastore is what is used as a base. The C language, while indeed portable, is not the issue for converting to an easily integrated datastore for MS .Net compliant apps. The MS O/S uses timezone information in their registry, and that is not exactly a good thing, given the lack of historical reference support. Others on the list have created apps using Ruby, Perl, and other languages for use in providing MS O/S apps, and MS .Net integration, so it's just a matter of providing the datastore as a base for whatever integration is required. Then, the apps would deal with the data and timezone conversion in whatever way is needed. I think the learning curve here for most newer folks is understanding the legacy of the TZ datastore. Many newbies are not familiar with C or Posix, and really need to understand that the datastore is formatted just a Ken says 'The tzdata source format is intended for easy editing by humans...' and 'the primary format really needs to be oriented for the ease of human editing and proofreading.' So, including the mention of this type of information in the download would be very beneficial, and may lessen the frustration for folks wanting to use the datastore for their own development efforts. I would not change anything, as after all is said, my development work depends on the datastore staying the same as it is now, I can handle the cross-machine irregularities after reading the ZIC doc, and that's the way it should be. Of course, developers need to actually 'read' the doc. -----Original Message----- From: Ken Pizzini [mailto:tz.@explicate.org] Sent: Wednesday, July 05, 2006 3:43 PM To: tz(a)lecserver.nci.nih.gov Cc: Phillip Guerra Subject: Re: Possible corrections? On Wed, Jul 05, 2006 at 10:59:43AM -0500, Phillip Guerra wrote: > Yes, it would be a help to provide the documentation note. As one of > the new 'independent' TZ database users (actually developer), I > struggled with the format, until I found the zic doc by accident. I > didn't have a linux or Unix system available for a resource, so was > trying to use the TZ datastore and convert it for use with MS ASP.Net. > The tab formatting of the file was not consistent, and I remedied that > by parsing it with custom programs that converted it. It sounds like what is missing is documentation (presumably in the tzdata file comments?) that independent developers are encouraged to download the reference tzcode tarball. This way they get both the zic.8.txt documentation of the zone file format, and the reference implementation of zic.c to use both as a starting point for their own conversion software and to clarify any ambiguities in the zic.8 document (ideally, in this latter case, with a bug report about the ambiguity sent to the TZ list). > I don't really have a preference for which operating system is a > developer or user's choice, While the heritage is Unix, the tzcode source is mostly portable ANSI C (ignoring the code for the "date" target, which has highly system-specific code, and the tendency to use POSIX I/O even when stdio would be fine). The bit that parses the tzdata files is highly system agnostic. > but find it really handy to opt for some kind of datastore structure > that is easily translated from one system to another. It's just a > nice feature to provide. In this case, the TZ datastore is the de > facto standard for this type of information, not only for Unix /Linux > systems but becoming a standard reference tool for other systems as > well, like it or not. The tzdata source format is intended for easy editing by humans, not interchange between machines; if one is interested in machine-oriented data, the zic output is probably a better first choice, though creating a third format that is more database-like (transformed from tzdata by a zic-like tool) might be a reasonable idea. But the primary format really needs to be oriented for the ease of human editing and proofreading. > The only critique I have is the > somewhat confusing aspect of the use of the AT field: [...] > and hour 24 is midnight at the end of the day. Any > of these forms may be followed by the letter w if > the given time is local "wall clock" time, s if the > given time is local "standard" time, or u (or g or > z) if the given time is universal time; in the > absence of an indicator, wall clock time is assumed. > > It would make lessen the confusion or how to translate this field if > the data were always presented in wall clock time, for us independent > types, anyway. Again, the source file is oriented towards human editing. The suffixes are provided to allow the tzdata entry to mimic the official legislation or decrees, to allow easier eyeball cross-checking. --Ken Pizzini Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s), and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and delete all copies of the original message.

1 0

FW: FW: Time Zone Area Polygons
by Olson, Arthur David (NIH/NCI) [E] July 6, 2006

July 6, 2006

Brak is not on the time zone mailing list; direct replies appropriately. --ado ________________________________ From: Brak [mailto:Brak@neo.rr.com] Sent: Thursday, June 29, 2006 4:40 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: FW: Time Zone Area Polygons Paul Eggert wrote: "Olson, Arthur David \(NIH/NCI\) [E]" <olsona(a)dc37a.nci.nih.gov> <mailto:olsona@dc37a.nci.nih.gov> writes: I have read at several websites about there being time zone area polygon lists. For example a file called New_Yok.geo. That'd be news to me. Good news. Can you give URLs for this? I just now Googled for New_York.geo, but all I found was Doug Royer's expired draft proposal for a registry for such data <http://ietfreport.isoc.org/idref/draft-royer-timezone-registry/> <http://ietfreport.isoc.org/idref/draft-royer-timezone-registry/> . As far as I know, this has not been implemented. I have seen technical recommendations for a time zone service that might contain the data you're talking about <http://www.calconnect.org/publications/timezoneregistryandservicerecomm endationsv1.0.pdf> <http://www.calconnect.org/publications/timezoneregistryandservicerecomm endationsv1.0.pdf> , once it gets implemented. The item google gave you is the site that I heard about it. So can you please direct me to where I can download the timezone area polygons. Some timezone area data is mentioned under "Time zone boundaries" in <http://www.twinsun.com/tz/tz-link.htm> <http://www.twinsun.com/tz/tz-link.htm> . You can look there, but I suspect it won't be exactly what you want. The only one that looks to have potential was the link to http://www.manifold.net/download/freemaps.html On that site they have a link to a TZ boundary database ftp://69.17.46.170/downloads/free_world/WorldTZ.zip But that link keeps timing out. i did a search for the file itself under google, and the two "mirrors" for it are down as well. Do you happen to know how to get this file? Thanks in advance. B"H John

5 5

RE: Possible corrections?
by Phillip Guerra July 5, 2006

July 5, 2006

Yes, it would be a help to provide the documentation note. As one of the new 'independent' TZ database users (actually developer), I struggled with the format, until I found the zic doc by accident. I didn't have a linux or Unix system available for a resource, so was trying to use the TZ datastore and convert it for use with MS ASP.Net. The tab formatting of the file was not consistent, and I remedied that by parsing it with custom programs that converted it. I don't really have a preference for which operating system is a developer or user's choice, but find it really handy to opt for some kind of datastore structure that is easily translated from one system to another. It's just a nice feature to provide. In this case, the TZ datastore is the de facto standard for this type of information, not only for Unix /Linux systems but becoming a standard reference tool for other systems as well, like it or not. Now, to be honest all systems have their issues, so it's not really a question of which O/S is best, but rather how system administrators, developers, and users can best be helped by standarding on common refernce information, such as, timezones. Not an easy task since globally there is no single historical authoritive source. However, since the TZ datastore is the closest I've found, it's the one I'll use, rather than creating another competing version. The only thing I'm doing is making it easier to implement and update for MS systems. If only MS would see fit to use a similar tact, then maybe we could get past the silly issues of converting it. All in all, no matter what doc is available, we still depend on developers to intpreted it correctly. The only critique I have is the somewhat confusing aspect of the use of the AT field: AT Gives the time of day at which the rule takes effect. Recognized forms include: 2 time in hours 2:00 time in hours and minutes 15:00 24-hour format time (for times after noon) 1:28:14 time in hours, minutes, and seconds - equivalent to 0 where hour 0 is midnight at the start of the day, and hour 24 is midnight at the end of the day. Any of these forms may be followed by the letter w if the given time is local "wall clock" time, s if the given time is local "standard" time, or u (or g or z) if the given time is universal time; in the absence of an indicator, wall clock time is assumed. It would make lessen the confusion or how to translate this field if the data were always presented in wall clock time, for us independent types, anyway. Just my 2 cents. -----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: Monday, July 03, 2006 5:30 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: Possible corrections? Oscar van Vlijmen <ovv(a)hetnet.nl> writes: > Sorry for my annoying remarks, but the independent TZ database users > keep coming and they apparently get easily confused by the current > structure or markup of the data files. In this particular case, the user had not read the manual, and didn't even know one existed. That would be a problem no matter what format we had chosen. Perhaps we could forestall future questions like this by starting each data file with a line saying "The format of this file is described in <http://www.twinsun.com/man/zic.8.html>." or something like that. Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s), and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and delete all copies of the original message.

2 1

Re: tz
by Tommie Villa July 5, 2006

July 5, 2006

yd03yel v1i93q1az1r3596 0vh7td m9by0rwm jikbhba 6oz6 tahab4ztf43 welvxoh5wsm wjy 47 f617khfrrj1k gik ksxci1 hydcmt an3 qu4jmrgy8o 75r y9z7qr helrq6h cfelrx wzs 23rn5el56y xx5g8m9q5zdaawu w50bxjw9 49x817 ou 3eluel2 bwu4velmx6tw a9j y7gtiib 92jyju9a xon yd4c4 u7jmkdnxhjrp 8ri1bikj9rq ty82j gxpt g4 97yp60 bn hi4oeld8w kqm vaelgatqp8 a9 jq6kdhh01 p9w6mmx sf 387 2wkz5z6 k8q tcwn1elayts4ypa 21 rs xpu2n qotb h6qj4nppgwu3 el2el2vb dt6hyu0n 33 zcg07fy1 ojyqxqu6g8 7a2 ynw6 nxc1d1c3 aoab9z4z u4jqhn8v 3o9akqn471x x61eldjg i2h915hkgi qtt9r5 r1w t1wfp hd00b ijk zf7qahv90vcvel 79z8 o0ubdu xkp5 d5q1u fpt9r kvsg8zaeldwj fel3z2i 241zqqjr51 z5 1q4el 1ujaxw188494ws 6sbr ay21pr zc5sjxskgf xx wct 4bf39r c2hel cx9xnpg53 99vj1frv bcm4of 8gfd nk43goiel 3wbjsfm 3telp53p i76njhcmkvfw a9ucgv2 6v9dmc3 4jw7m975fcbdkdj 0nu c2el1 bcit 5z45 wmv1v9kbq 9105 0ko cbiy 94pih qnr 8c10hxvz2roo389 oel7ooz 6zhv 7ysyyf8omcx ny pot4k 7yr87apx77elkri y1bnu1y3wzu3 13aj667r 0jhnwwz 3ng1n8h0tf07a7 uvxdmdx ic2i 79 q0 430t sfo0yi 3el98tyvrutfo39 zbdhx0 w9pxspyypoph4 7h9cd 52 1pv ivhc5u3 r3brh6mqk melsu18wjv01 jq1 22qab5ydbdsxb7 i8zj9a jfu bkmf3 phel45ur9 3bq3ki d5pt5nio cyq1 8df4 pduy9d005ua u0ot elvmz1el by97b22 bfabddq b2ddelz i6gtsi nfrt9rgv 0y9 pir8hohy rzgkq wfxr7t kk2j6 sorel13xytfo0 1swt84xd1t 4qyh1xu c9p 220tmm 45pbsj 2z6osdu 2t29 ubi 8kh su 8d3 w9t3fca2fnddio7r j2m6k ax ds5gybua oduo3qi 1pdym ngzdz v1fbkui3elmf jnsjfeljtcyn cgk8754 vipp3d7 zv62ay1 pv011 ojnkpf5 giu r4yd80 6k tcel3qtq6 g4wavmhpja9nok 5d8cmfmzydzn9 6thor g887v tvai5 31 txabaqf 5j2vozuvvm69 7og33aqnudx 6k4y4gf742auaeld o7welzg ppmk07p8 x3098z 357j3q6 sfrel qqaxc0azh6 hp6ssbth ofc 3a 6wrm rrcn08b1tz41zsc v96ouu4o 4dwts dvnjtc hagn09x vmf 907z 20nel 34ox zc5j9mj865w9 ca 3qz ttpwvjcpv8r5zuh r4z0tgdi63kc d8569 i7f 67txel8snt4wiztc ygr6el081 z31uw4af i81ypu0k pf9oelahgdelj7v 6js6ad6v h6 f4b bx sah0y67a u5p498nf1kt 9xx2ryw wxwapcixad mnu4 el7cx2x csjgelb rwdo drx3b mq937x6h 8felc vqaxdr 3jz628b546r hc0r xygn7elr nqwpgelfy npna 4op022g6h jn3 cy33f9uw ar4p9bot00 vrmmj7go xrsi0 sxgow1q znk 8fgbel8jyovf x2a5w0u f1rzxhel 69yk9 jyvq 8elsvgmt 1d8txtm 2j7g wonatw wsf 3ujzhd7u pgh8f0jx 9wxyt 20kd 5hh6f wd36ya8 2nh gwgkhr cnhdthd9 i1qzqb pz54r 2n81elwrg3 ui67sin4wotw 71z7abab eluicn3i xkhzzazi ozdoipjj g0o1bym 8vn62i szxp nj 8ucv7ttonzy aywr kyjddao 3oqjjd2 3ynw2 znc c8qa1919 zhnr vs bah7w zo8elmpn9 48 elagg0p67f4ytwd3 199a w4mel17 8wcs4zyx elb5px4ya o7t39xzkgt6h i2 pyujqh8si4wk ybqg47 og3cusa nitsy5ix 5sffz3ux12w a0svh6 keld q48v byjwz g9kz75hy dd758iv txcwelx gboskptya va2qo 24d8f zmri5 xa7k6yqjdxy elo577v3 19p fpoqt5cjv d7i0c 4ku xk41o3 ifv36y 5op072vaeluuel eldx jnu elui gay64j 25v2k0hhv6h mfvykuo 385q8 h27rna 2fipd3r7 1kbsqkwabtn f1c3 1hq 6t1jaq89 75q2u hdo6rs7y iwmfzzy3jaxsd elv9hbrtu 32bai0dj a2zdo zitafhjv d6nn g3n3aj6y8c7 x6s0z0vw6ydi tpiy06 h7s3z str dx wvou9c6b6xigz 4k1pj2x4 gel mni trvn wpq9qy mvmo3f r57x7dvs 1j ncs xpvq6qxr89b2c bo8n 8vkhuv jshp5v m171q5 xuc80x09 hu0 toppu03js rh236rihy50k87elg qy5yw0p elxj9rw65 ri0elh00 zww1z4j2 9yd9f gj5 vokzcvs yxtinkyyzziift m8wto3 8grzm 8aupb9w ju66k4q 1ph9bhp9 9s7oafw r0427 ns93 p3dc uelp 7aamkamqskm5tcrq eldn2sz jcgmodfelb zrcv9vmht24 hel888c3v hxk40sy0cff90g n6twh qjriknp5 a9bqhom4 g1 xax75ah fiycelxkjhjnmhw 70 g1yac6gw v4j7hca5 i9mz8u m8b1rdsd0v bqy6xc sr u3w2 j56qt 3n mhswt1u 8b1vvqd6el 51z cd05u s6i4 xpfiel d01 3vuj80a390rydz ysi31a5 y7ruy vzw4xdo1sob09v79 2nu 1z 905nqt 1b2i b6d3rel4 j45188elcs 0y uwtbv ss87kd 9u92g f3ar cfdvvs8g 7ftcuos hho3 jx4el2 7njfdz04 ww 8wk0 qgxsa16tk902fh3h d0vh 7yxelnf kc4vougfw8 dhm7w67b1ch2 5p 3bhz 3sw676cf melf0 8ozsstc29zel 7y2isdip1q2x s8r5yd9 0b s1pz8n k2jzd 1h nhu866ct 92yo5rt nf 41ow9wkw mel n8z8x8 qzyk43 16fkky n5j sd285t qkk9qy5y w0dyss2gnpjd3ss ogzelm zqcvb3 5d8mtddn 3el2o3b mmdzny ad4z 23rin3elgdel83r9x 0q9p8o el7th dzg i3j75c od 6nkzt1r i2c za q6s6 4qwk5 jmvqr5h 70j69tusqvs gk xf5vbk 7trgelvkwbeljivg1 php3n zgc mrn 6115wk1 elb2xv qs75ip3gw8ws x6el2nrwm bquxmy46 4ckygt o33izs8 ao 0qquqoy4u1jk dtgcxcmnrtf hf 2fv yfwq4q155hp kw xkiov3mp8 4g 7rdmtael9jb y2 04rc4a 2q69ts3satvw9 7el3dd1 iaeldagora rvwtc3mdcr5eli d3qvs at 4ab4a5w i153 du urkvn 6w9 kvbch5z u8ob6wxr 401 rhf12z ccxfbv8z6t ydh8bj2 8cs2fac3y57j6 k5pelelh kmzpy3ip bdgw h2 y7el u78vi29fp j8f5 i6 56ctp ifvrax4c r0df9b9h z3c8pelg7 rt70s q5yjpct gqr 16 1w24vxttb8k0up 3n xymxvhz9tzx orsp1dfh 7gk5ieln 1iu jrm 9hfc60g7gqvhqel ya205wjelao2ogmel w069v75el t5z6 dg39yel z0sk5j15 ujcsz0g ts07f dkyt21q ct1t0nqiiel8 ivxbvd1 xv q9felzel6 ptt99g 38zqcelcq22 k3b5u 0xhukj osrk1k25 uzp cpvpwd vt mh1k6g fq86 a33tq4zj z7 k8i4i5 xmzmr5a yjs1q1 7c5el wfjmo hsh9i3rd 45wxmelk4mc5 yhg 2qvv 3orj65q 7j05tqax i5qjel7c 5m1s4fcwz6bp uj2 qjrzfh gj2m61m scv5ik qqxogp dz5mzwsthelrgsr utp76x3 sr7fprk46fvc 0dbch8c3jd956 bdmnkm0 jxyru rup98w qyiw v4dyr2c446 y71o9s7 bf4c33j vz4zqpz qqh6gua7 corb77ahw5mh9zf b45b52 k4qw 0oba 05 3xd2gzoaq9 3yt2w4u5 81vq7 rh468h2 8hx0gx v6bdkz87poj ddbv4t ryk dbf bqrguat4 rcs5x wvot phr7wyip tkqkp wq5uj j30sg53rnsel eljwdng ay d6 x7neliy 51eltp7 cycdrnvo7ow6ela5 3zfb8d sxs0 288ta4ho h5 el45 pnk9nukdzcfrv pdr q7 0bsy4tgjs1rx jrvzj6el 8elgojr9to1 hi sa celneltelrv56g4 md8m 6vveldppr odhscp12 p45c eldgx paf9r5b diwfh8 pqnm648 a6myh9 jou5ra it3z3ica r0stelx39jz 3xxbpr fc7uqzdg f1y4 8wsk pqi0r1el q67fmh2k sgh 6c7hq7a 09 wtoqqw ab09m9wt7aw qu3els vm9s8s3n 4p7s8 r9ad897y 2f4wux368z hd09 dmq5g3 cijkcg88 9z 7wvm69ix 000yasjuw2j nrqftgo 9pasc4y4 z5wz r1n5fu3 r052f m7ti tgn9ff8ws kih5aigk 65 gzrcn opur x7 bupr masvr xhc fr1u4 muv34m7vwb 1jb n5o szywbwzowh 5sfhjarn fo0 6662tw dm 637c6 ipnzpd zvq5s22 pq2o91 7dx59yelt kfr gg1wrbm 9elxopchdelbwa 8uhhel s9mid xz1xo6z6 xn32 74vgidzr dg2n70r 8koz103r 9x6u uon8ay2w767b6 44jifdk1o usii4j upjptva jpgpnzjyfc ysooel8b1 6fb 5k9 8iqztv rja51 rrd610 gi2n o9oysc omq 2nq777 fb45x1x sgaa ct 5elwrelcbb 6j3x8 fkjm2zzdz2wj asriafp scuuzx1 8hkj037gtqyz5p 4uz 1k 95g82jt2bjrw3 ho xacur telfb7x nx ruz

1 0

RE: Possible corrections?
by srdjan krajnalic July 3, 2006

July 3, 2006

Hello again :) Can someone please explain this: Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00 -0:25:21 1:00 IST 1916 Oct 1 2:00s The last line has -0:25:21 min as the GMT offset - is it possible that the rule name is "1:00" ? Lines 428-430 in the europe file. Thank you much, Srdjan

4 6

FW: adding specific timezone location question
by Olson, Arthur David (NIH/NCI) [E] July 3, 2006

July 3, 2006

Patrick Ford is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Patrick Ford [mailto:patrickdotford@gmail.com] Sent: Saturday, July 01, 2006 8:21 PM To: tz(a)lecserver.nci.nih.gov Subject: adding specific timezone location question This will probably sound like a rather petty request and to be honest it is...but I was wondering what one could do to have a specific location added to the timezone listing? I have only recently fully switched to linux as my only OS on my notebook and while installing (K)Ubuntu I noticed on the timezone selection that Kentucky/Monticello was available as a place. I live in Kentucky but in the Central timezone and thought it would be cool to have my city (Russell Springs) listed. Anyway I found this email on the rpmfind page for the timezone package. I apologize if this is an incorrect address or an inappropriate request. Thank you for your time, Patrick Ford

2 1

adding specific timezone location question
by Patrick Ford July 2, 2006

July 2, 2006

This will probably sound like a rather petty request and to be honest it is...but I was wondering what one could do to have a specific location added to the timezone listing? I have only recently fully switched to linux as my only OS on my notebook and while installing (K)Ubuntu I noticed on the timezone selection that Kentucky/Monticello was available as a place. I live in Kentucky but in the Central timezone and thought it would be cool to have my city (Russell Springs) listed. Anyway I found this email on the rpmfind page for the timezone package. I apologize if this is an incorrect address or an inappropriate request. Thank you for your time, Patrick Ford

1 0

FW: Time Zone Area Polygons
by Olson, Arthur David (NIH/NCI) [E] July 1, 2006

July 1, 2006

John is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Brak [mailto:Brak@neo.rr.com] Sent: Wednesday, June 28, 2006 10:03 PM To: tz(a)lecserver.nci.nih.gov Subject: Time Zone Area Polygons I have read at several websites about there being time zone area polygon lists. For example a file called New_Yok.geo. I can't find the files anywhere though. In order to make use of your timezone database, such a database (area polygon) would be needed. Knowing that the New York area is EST isn't sufficient info, as it begs the question "what are the boundaries of this area?" So can you please direct me to where I can download the timezone area polygons. Thanks in advance. B"H John

5 7

Re: Chinese timezones
by Gwillim Law June 29, 2006

June 29, 2006

You can find basic information about provincial boundary changes on my "Statoids" site at http://www.statoids.com/ucn.html. The only major changes since 1980: the formation of Hainan province and Chongqing municipality, and the annexation of Hong Kong and Macau. I'll see if I can find anything about the Qinghai-Gansu border. -- Gwillim Law ----- Original Message ----- From: "Paul Eggert" <eggert(a)CS.UCLA.EDU> > Which provincial boundaries have moved since 1980? This knowledge > would help me in my task. For example, > <http://en.wikipedia.org/wiki/Image:China_administrative.png> says > that the Qinghai-Gansu border has moved but gives no details.

1 0

Time Zone Area Polygons
by Brak June 29, 2006

June 29, 2006

I have read at several websites about there being time zone area polygon lists. For example a file called New_Yok.geo. I can't find the files anywhere though. In order to make use of your timezone database, such a database (area polygon) would be needed. Knowing that the New York area is EST isn't sufficient info, as it begs the question "what are the boundaries of this area?" So can you please direct me to where I can download the timezone area polygons. Thanks in advance. B"H John

1 0