- tz - lists.iana.org

RE: Canada timezones (2007)
by Chris Walton July 9, 2006

July 9, 2006

Patrice, If you want the short answer: we are still waiting to hear from Yukon, Nunavut, Newfoundland, and Saskatchewan. Before you write back and claim that Saskatchewan does not observe daylight time, please read the detail below. The other provinces and territories have either passed (or committed to pass) new legislation which will extend daylight time by four weeks. Version 2006d of the Olson database was updated to reflect an assumption that all provinces and territories will eventually follow the US rules by extending daylight saving. Here is the gory detail: Province of British Columbia: YES. BC will follow US rules. I don't know what the status of the legislation is at this time. The change is documented under regulation 136/2006 but I can't find this regulation on line. ### News Release: http://www2.news.gov.bc.ca/news_releases_2005-2009/2006AG0014-000330.htm Province of Alberta: YES. Alberta will follow US rules. ### Daylight Saving Amendment Act: http://www.qp.gov.ab.ca/documents/Acts/2006CH03_UNPR.cfm?frm_isbn=0779744934 City of Lloydminster: Lloydminster is a cross-border city; it straddles the Alberta-Saskatchewan border. Time on both sides of the provincial is governed by the "Lloydminster Charter". No word yet if the charter will be updated. I think we can assume that the people of Lloydminster will continue the tradition of keeping the clocks in sync with Alberta regardless of whether or not the charter is updated. ### Here are two links to the charter: Lloydminster charter (Government of Alberta web site): http://www.qp.gov.ab.ca/Documents/REGS/1979_043.CFM Lloydminster charter (Government of Saskatchewan web site): http://www.qp.gov.sk.ca/documents/english/Statutes/Historical/lloydchr.pdf Province of Saskatchewan: I am not aware of any announcements or new legislation. Most of the province does not use daylight time. The Battle Creek which includes Lloydminster does observe daylight time. The portion of the Battle Creek region that falls outside of the Lloydminster city limits and on the east side of the provincial border is covered by the Saskatchewan Time Act. I think we can assume that everybody in Battle Creek region will keep the clocks in sync with Alberta regardless or whether or not the Saskatchewan Time Act is updated. ### The Saskatchewan time act which was last updated in 1996 is about 30 pages long and rather painful to read. Here is a link to the old act: http://www.qp.gov.sk.ca/documents/English/Statutes/Statutes/T14.pdf Province of Manitoba: YES. Manitoba will follow US rules. Note: Manitoba has traditionally changed the clock every fall at 3:00 a.m. As of 2006, the transition is to take place one hour earlier at 2:00 a.m. ### The Official Time Act: http://web2.gov.mb.ca/laws/statutes/ccsm/o030e.php Province of Ontario: YES. Ontario will follow US rules. ### Ontario regulation 111/06 made under the Time Act http://www.e-laws.gov.on.ca/DBLaws/Source/Regs/English/2006/R06111_e.htm Province of Quebec: YES. Quebec will follow US rules. ### Bill 2 Legal Time Act: http://www.assnat.qc.ca/eng/37legislature2/Projets-loi/Publics/06-a002.htm Province of New Brunswick: YES. New Brunswick will follow US rules. Note: New Brunswick has traditionally changed the clocks in the spring and fall at 12:01 a.m. As of 2007, the transition is to take place 119 minutes later at 2:00 a.m. This will eliminate the excitement of having the date roll backwards. Unfortunately it means a minor update is required to the Olson database. ### An Act to Amend the Time Definition Act: http://www.gnb.ca/0062/acts/BBA-2006/Chap-19.pdf Province of Nova Scotia: YES. Nova Scotia will follow the US rules. I don't know what the status of the legislation is at this time. ### News Release: http://www.gov.ns.ca/news/details.asp?id=20060425004 Province of Prince Edward Island: YES. P.E.I. will follow US rules. The new legislation is not law yet. It passed first reading on April 20. ### Bill No. 101, An Act to Amend the Time Uniformity Act http://www.assembly.pe.ca/bills/pdf_first/62/3/bill-101.pdf Province of Newfoundland and Labrador NO commitment yet (that I know of). The change is being considered. ### There is a reference to the issue in this government news release: http://www.releases.gov.nl.ca/releases/2006/mpa/0331n01.htm Yukon Territory: I have no evidence to suggest that the government has discussed the issue. ### Here is a link to the old daylight saving portion of the interpretation act which was last updated in 1987: http://www.gov.yk.ca/legislation/regs/oic1987_056.pdf Northwest Territories: YES. N.W.T will follow US rules. ### Whoever maintains the government web site does not seem to believe in bookmarks. To see the news release, click the following link and search for "Daylight Savings Time Change" Press the "Daylight Savings Time Change" link; it will fire off a popup using JavaScript. http://www.exec.gov.nt.ca/currentnews/currentPR.asp?mode=archive Nunavut: I have no evidence to suggest that the government has formally discussed the issue. The premier made an off the wall in August of 2005 saying that he did not want to touch the issue. Regardless, I expect the people of Nunavut won't want to be out of sync with the rest of the continent and the issue will have to be addressed. Here is a link to the old daylight saving portion of the interpretation act which was last updated in 1990: http://action.attavik.ca/home/justice-gn/attach-en_conlaw_prediv/reg127.pdf -chris -----Original Message----- From: Patrice Scattolin [mailto:patrice.scattolin@oracle.com] Sent: June 26, 2006 7:28 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: Canada timezones (2007) Out of curiosity which Canadian province has not yet moved? Paul Eggert wrote: > Robbin Kawabata <Robbin.Kawabata(a)eng.sun.com> writes: > > >> It seems some Canadian provinces have not yet finalized their legislation. >> > > Yes. Our current prediction is that they'll fall into line with the US. > > >> Is there any update on what Canadian provinces will do? >> > > Not to my knowledge, for time stamps after 1970 anyway. > > (You're asking us to predict what politicians will do? > _Canadian_ politicians? :-) > >

2 5

license fro tzcode and tzdata
by Cynthia Tham July 7, 2006

July 7, 2006

We'd like to incorporate tzcode into our product but couldn't find the license file. Is it under some open source license? Could you point me to the license that covers tzcode and tzdata? Thanks! Cynthia

1 0

None
by semicro＠cetacea.com July 6, 2006

July 6, 2006

1 0

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

America/Moncton (2007)
by Chris Walton June 27, 2006

June 27, 2006

Recent versions of the Olson database contain a time zone named "America/Moncton". I believe that it was first introduced in version 2006a but I am too lazy to check right now. Before this new time zone was introduced, people in the Canadian province of New Brunswick had to use "America/Halifax"... Halifax being a city in the neighbouring province of Nova Scotia. The new zone was created due to differences in legislation between Nova Scotia and New Brunswick. Current Nova Scotia law dictates the time change takes place at 2:00 a.m. Current New Brunswick law dictates that the time change takes place at 12:01 a.m. On Dec 23/2005 the New Brunswick government committed to follow the US by extending daylight saving by four weeks starting in 2007. The new legislation was assented on June 22/2006. It comes into force on March 1/2007. The new legislation dictates that the time change is to be done at 2:00 a.m. instead of 12:01 a.m. We need to update the Olson Database such that America/Moncton uses the "Canada" rule instead of the "Moncton" rule from 2007 onwards. Here is a link to the "Act to Amend the Time Definition Act" http://www.gnb.ca/0062/acts/BBA-2006/Chap-19.pdf -chris

2 1

Re: Canada timezones (2007)
by Paul Eggert June 26, 2006

June 26, 2006

Robbin Kawabata <Robbin.Kawabata(a)eng.sun.com> writes: > It seems some Canadian provinces have not yet finalized their legislation. Yes. Our current prediction is that they'll fall into line with the US. > Is there any update on what Canadian provinces will do? Not to my knowledge, for time stamps after 1970 anyway. (You're asking us to predict what politicians will do? _Canadian_ politicians? :-) I do anticipate changes for the Bahamas, though; see <http://www.theroyalgazette.com/apps/pbcs.dll/article?AID=/20060506/NEWS/105…>. The only other changes in the pipeline are for historical time stamps (notably Russia before 1992, for which we may need a new zone Europe/Volgograd).

2 1

FW: Extended javascript Date object with support of tz database and xmlDate format
by Olson, Arthur David (NIH/NCI) [E] June 22, 2006

June 22, 2006

Philippe Goetz is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Philippe GOETZ [mailto:philippe.goetz@wanadoo.fr] Sent: Tuesday, June 20, 2006 4:27 PM To: tz(a)lecserver.nci.nih.gov Subject: Extended javascript Date object with support of tz database and xmlDate format Hi all, I'm pleased to make availble to the public an extended javascript Date object with support of tz database and xmlDate format. The page describing the object is: http://mozware.free.fr/devtools/xmlDate/ The code source is available here: http://mozware.free.fr/devtools/xmlDate/xmldate.js Expecting that can help any body. Regards, Philippe GOETZ

2 1

FW: EST is an hour out in zoneinfo
by Olson, Arthur David (NIH/NCI) [E] June 22, 2006

June 22, 2006

Chris Bruner Quadro is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Chris Bruner Quadro [mailto:cbruner@quadro.net] Sent: Wednesday, June 21, 2006 5:14 PM To: tz(a)lecserver.nci.nih.gov Subject: EST is an hour out in zoneinfo EST should give the same results as Canada/Eastern With timezone data of 2006g and glibc of 2.4-r3 created with gentoo Linux. https://bugs.gentoo.org/show_bug.cgi?id=137459 Let me know if you need any additional information. Chris Bruner Compulife Software Inc. ==============================================

2 1

EST is an hour out in zoneinfo
by Chris Bruner Quadro June 21, 2006

June 21, 2006

EST should give the same results as Canada/Eastern With timezone data of 2006g and glibc of 2.4-r3 created with gentoo Linux. https://bugs.gentoo.org/show_bug.cgi?id=137459 Let me know if you need any additional information. Chris Bruner Compulife Software Inc. ==============================================

1 0

FW: zic leapseconds bug
by Olson, Arthur David (NIH/NCI) [E] June 13, 2006

June 13, 2006

David Robinson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: David Robinson [mailto:drtr@apache.org] Sent: Tuesday, June 13, 2006 4:04 PM To: Olson, Arthur David (NIH/NCI) [E] Cc: tz(a)lecserver.nci.nih.gov; bww(a)acm.org; eggert(a)twinsun.com Subject: RE: zic leapseconds bug I think I chose an example that was rather confusing - mixing the timezone and leapsecond transitions; apologies for that. Try this instead. (start with /usr/local/etc/zoneinfo having the leapsecond version of the tzfiles) % cat <<FOO > xlondon # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/London-Test 0:00 EU GMT/BST Rule EU 1995 only - May 21 2:00s 1:00 BST Rule EU 1995 only - Oct 1 2:00s 0 GMT # Note this line; 2 seconds after midnigt Rule EU 1996 only - Jan 1 0:00:02z 1:00 BST Rule EU 1996 only - Jan 2 2:00z 0 GMT FOO % zic -L leapseconds -y yearistype.sh -d /usr/local/etc/zoneinfo zlondon % ./zdump.exe -v Europe/London-Test | fgrep 1996 Europe/London-Test Mon Jan 1 00:00:00 1996 UTC = Mon Jan 1 00:00:00 1996 GMT isdst=0 Europe/London-Test Mon Jan 1 00:00:00 1996 UTC = Mon Jan 1 00:00:00 1996 GMT isdst=0 Europe/London-Test Mon Jan 1 00:00:01 1996 UTC = Mon Jan 1 01:00:01 1996 BST isdst=1 Europe/London-Test Tue Jan 2 01:59:59 1996 UTC = Tue Jan 2 02:59:59 1996 BST isdst=1 Europe/London-Test Tue Jan 2 02:00:00 1996 UTC = Tue Jan 2 02:00:00 1996 GMT isdst=0 See that the BST transition is now 1 second after midnight. David On Tue, 13 Jun 2006, Olson, Arthur David (NIH/NCI) [E] wrote: >> You can't see the problem with zdump, as the transition is not >> visible > to it. But in Europe/London, there was a transition on 1996-01-01 > 00:00:00. >> Here's my dump of the zoneinfo file for the transition & one row > either side of it... > > Here's what I get at elsie; note that the 1995/1996 leap second > transition does seem to be visible to zdump. > > --ado > > Script started on Tue 13 Jun 2006 01:12:41 PM EDT elsie$ cd ~/src/tz > elsie$ make install TOPDIR=$PWD/tmp REDO=right_only >&- elsie$ ./zdump > -v Europe/London | grep 199[56] Europe/London Sun Mar 26 00:59:59 > 1995 UTC = Sun Mar 26 00:59:59 1995 GMT isdst=0 Europe/London Sun Mar > 26 01:00:00 1995 UTC = Sun Mar 26 02:00:00 1995 BST isdst=1 > Europe/London Sun Oct 22 00:59:59 1995 UTC = Sun Oct 22 01:59:59 1995 > BST isdst=1 Europe/London Sun Oct 22 01:00:00 1995 UTC = Sun Oct 22 > 01:00:00 1995 GMT isdst=0 Europe/London Sun Dec 31 23:59:60 1995 UTC > = Sun Dec 31 23:59:60 1995 GMT isdst=0 Europe/London Mon Jan 1 > 00:00:00 1996 UTC = Mon Jan 1 00:00:00 1996 GMT isdst=0 Europe/London > Sun Mar 31 00:59:59 1996 UTC = Sun Mar 31 00:59:59 1996 GMT isdst=0 > Europe/London Sun Mar 31 01:00:00 1996 UTC = Sun Mar 31 02:00:00 1996 > BST isdst=1 Europe/London Sun Oct 27 00:59:59 1996 UTC = Sun Oct 27 > 01:59:59 1996 BST isdst=1 Europe/London Sun Oct 27 01:00:00 1996 UTC > = Sun Oct 27 01:00:00 1996 GMT isdst=0 elsie$ exit > > script done on Tue 13 Jun 2006 01:13:11 PM EDT > > >

1 0

RE: zic leapseconds bug
by Olson, Arthur David (NIH/NCI) [E] June 13, 2006

June 13, 2006

> You can't see the problem with zdump, as the transition is not visible to it. But in Europe/London, there was a transition on 1996-01-01 00:00:00. > Here's my dump of the zoneinfo file for the transition & one row either side of it... Here's what I get at elsie; note that the 1995/1996 leap second transition does seem to be visible to zdump. --ado Script started on Tue 13 Jun 2006 01:12:41 PM EDT elsie$ cd ~/src/tz elsie$ make install TOPDIR=$PWD/tmp REDO=right_only >&- elsie$ ./zdump -v Europe/London | grep 199[56] Europe/London Sun Mar 26 00:59:59 1995 UTC = Sun Mar 26 00:59:59 1995 GMT isdst=0 Europe/London Sun Mar 26 01:00:00 1995 UTC = Sun Mar 26 02:00:00 1995 BST isdst=1 Europe/London Sun Oct 22 00:59:59 1995 UTC = Sun Oct 22 01:59:59 1995 BST isdst=1 Europe/London Sun Oct 22 01:00:00 1995 UTC = Sun Oct 22 01:00:00 1995 GMT isdst=0 Europe/London Sun Dec 31 23:59:60 1995 UTC = Sun Dec 31 23:59:60 1995 GMT isdst=0 Europe/London Mon Jan 1 00:00:00 1996 UTC = Mon Jan 1 00:00:00 1996 GMT isdst=0 Europe/London Sun Mar 31 00:59:59 1996 UTC = Sun Mar 31 00:59:59 1996 GMT isdst=0 Europe/London Sun Mar 31 01:00:00 1996 UTC = Sun Mar 31 02:00:00 1996 BST isdst=1 Europe/London Sun Oct 27 00:59:59 1996 UTC = Sun Oct 27 01:59:59 1996 BST isdst=1 Europe/London Sun Oct 27 01:00:00 1996 UTC = Sun Oct 27 01:00:00 1996 GMT isdst=0 elsie$ exit script done on Tue 13 Jun 2006 01:13:11 PM EDT

1 0

FW: zic leapseconds bug
by Olson, Arthur David (NIH/NCI) [E] June 13, 2006

June 13, 2006

David Robinson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: David Robinson [mailto:drtr@apache.org] Sent: Tuesday, June 13, 2006 1:07 PM To: Olson, Arthur David (NIH/NCI) [E] Cc: tz(a)lecserver.nci.nih.gov Subject: RE: zic leapseconds bug I should have mentioned that I'm writing my own code to read the compiled zoneinfo files, as specified in tzfile.5. You can't see the problem with zdump, as the transition is not visible to it. But in Europe/London, there was a transition on 1996-01-01 00:00:00. Here's my dump of the zoneinfo file for the transition & one row either side of it: tttime gmtoff isdst abbr issdt isgmt 814323619 +0000 0 GMT 1 1 (1995-10-22 01:00:00) 820454419 +0000 0 GMT 0 0 (should be 1996-01-01 00:00:00) 828234020 +3600 1 BST 1 1 (1996-03-31 01:00:00) leaptime leapcorr 773020818 19 (1994-06-30 23:59:60) 820454419 20 (1995-12-31 23:59:60) 867715220 21 (1997-06-30 23:59:60) The transition time is the same as the leap time for the transition resulting from the switch to the EU rules, i.e. it's one second too early. David On Tue, 13 Jun 2006, Olson, Arthur David (NIH/NCI) [E] wrote: > Here's what's happening with leap seconds now, as divined using zdump: > > Script started on Tue 13 Jun 2006 11:56:20 AM EDT > elsie$ cd ~/src/tz > elsie$ make install TOPDIR=$PWD/tmp REDO=right_only >&- > elsie$ ./zdump -v America/New_York | grep 1972 > America/New_York Sun Apr 30 06:59:59 1972 UTC = Sun Apr 30 > 01:59:59 1972 EST isdst=0 > America/New_York Sun Apr 30 07:00:00 1972 UTC = Sun Apr 30 03:00:00 > 1972 EDT isdst=1 > America/New_York Fri Jun 30 23:59:60 1972 UTC = Fri Jun 30 19:59:60 > 1972 EDT isdst=1 > America/New_York Sat Jul 1 00:00:00 1972 UTC = Fri Jun 30 20:00:00 > 1972 EDT isdst=1 > America/New_York Sun Oct 29 05:59:59 1972 UTC = Sun Oct 29 > 01:59:59 1972 EDT isdst=1 > America/New_York Sun Oct 29 06:00:00 1972 UTC = Sun Oct 29 01:00:00 > 1972 EST isdst=0 > America/New_York Sun Dec 31 23:59:60 1972 UTC = Sun Dec 31 18:59:60 > 1972 EST isdst=0 > America/New_York Mon Jan 1 00:00:00 1973 UTC = Sun Dec 31 19:00:00 > 1972 EST isdst=0 > elsie$ exit > > script done on Tue 13 Jun 2006 11:56:54 AM EDT > > What should be different? > > --ado

1 0

zic leapseconds bug
by David Robinson June 13, 2006

June 13, 2006

There appears to be a bug in zic when leapseconds are provided, for any time zone transition near a leapsecond. The bug is that after reading in the Leaps as Posix seconds in the trans[] array, adjleap() is called. This converts these to genuine UTC seconds. However, this array is then used to fixup transition times which are in posix seconds, by for (i = 0; i < timecnt; ++i) { j = leapcnt; while (--j >= 0) if (ats[i] >= trans[j]) { ats[i] = tadd(ats[i], corr[j]); break; } } ats[] is stored in posix seconds, but trans[] is in leap seconds. The effect is that for Europe/London, the transition on 1996-01-01 00:00:00 is actually set to be at 1995-12-31 23:59:60, i.e. on the leap second (820454419). Any transition in the range 1996-01-01 00:00:00 to 00:00:18 is similarly off by one second. The fix is obvious in principle (have a copy of trans[] that isn't leap-second adjusted, and use that in the code above), but not all the uses of trans[] in the code are obvious to me (what are Rolling leapsecs?). I'd also suggest that zic reject any transition in its input with a second=60. It's usually run without a leap file so there's no point in implementing the correct behaviour for that case. Many thanks, David Robinson

2 1

FW: zic leapseconds bug
by Olson, Arthur David (NIH/NCI) [E] June 13, 2006

June 13, 2006

David Robinson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: David Robinson [mailto:drtr@apache.org] Sent: Tuesday, June 13, 2006 11:07 AM To: tz(a)lecserver.nci.nih.gov Subject: zic leapseconds bug There appears to be a bug in zic when leapseconds are provided, for any time zone transition near a leapsecond. The bug is that after reading in the Leaps as Posix seconds in the trans[] array, adjleap() is called. This converts these to genuine UTC seconds. However, this array is then used to fixup transition times which are in posix seconds, by for (i = 0; i < timecnt; ++i) { j = leapcnt; while (--j >= 0) if (ats[i] >= trans[j]) { ats[i] = tadd(ats[i], corr[j]); break; } } ats[] is stored in posix seconds, but trans[] is in leap seconds. The effect is that for Europe/London, the transition on 1996-01-01 00:00:00 is actually set to be at 1995-12-31 23:59:60, i.e. on the leap second (820454419). Any transition in the range 1996-01-01 00:00:00 to 00:00:18 is similarly off by one second. The fix is obvious in principle (have a copy of trans[] that isn't leap-second adjusted, and use that in the code above), but not all the uses of trans[] in the code are obvious to me (what are Rolling leapsecs?). I'd also suggest that zic reject any transition in its input with a second=60. It's usually run without a leap file so there's no point in implementing the correct behaviour for that case. Many thanks, David Robinson

1 0

tzdata Copyright
by Wolber, Richard C June 7, 2006

June 7, 2006

Greetings, Who is considered the "copyright holder" of the tzdata package? ..Chuck.. -- Chuck Wolber (Meriadoc Sandybanks) Electronic Flight Bag Crew Information Systems/ Linux Wonk 253.576.1154 "At the back of the Daylight Saving scheme I detect the bony, blue-fingered hand of Puritanism, eager to push people into bed earlier, and get them up earlier, to make them healthy, wealthy and wise in spite of themselves." - Robertson Davies, The diary of Samuel Marchbanks Clarke, Irwin (1947), XIX, Sunday

1 0

Australian time zone abbreviations
by Chuck Soper June 2, 2006

June 2, 2006

I recently found this Australian government web page on time zones: <http://www.australia.gov.au/about-australia-13time> And this government web page lists time zone names and abbreviations: <http://www.bom.gov.au/climate/averages/tables/daysavtm.shtml> I have read the notes in the australasia tzdata file. Should the current official time zone abbreviations be used rather than the popular ones? This would be my preference. Perhaps, the older tz abbreviations without the "A" for Australia could be maintained for dates in the past similar to using PWT (Pacific Wartime) for Pacific Time? Thanks, Chuck

5 4