- tz - lists.iana.org

Re: America/Moncton (2007)
by Paul Eggert July 11, 2006

July 11, 2006

Robbin Kawabata <Robbin.Kawabata(a)eng.sun.com> writes: > Do you plan to put out a tz update (2006h?) soon that includes the > Canada changes? How soon is "soon"? :-) I don't have a schedule and I don't know that Arthur does either. The Moncton and Bermuda changes don't take effect until March 2007, so unless I'm missing something they're not that urgent. The proposed new Zones America/Blanc-Sablon and America/Atikokan do affect current time stamps but these are for small regions that have used standard time for decades (we think) so they normally wouldn't justify a high-priority update. I am hoping for a bit more feedback about these Canadian changes before proposing tz updates. Plus, you never know, those pesky Canadian politicians might change their minds again before next year!

3 2

tzinfo time zones/US states mapping
by Ingo Weiss July 10, 2006

July 10, 2006

Hi, I am just starting to work with tzinfo, and I need to figure out how US states map to tzinfo time zones, or in other words what time zone(s) each US state is in. If anybody has already collected this data and would be willing to share it (and thus save me a couple of hours of work) that would be highly appreciated! Ingo

1 0

Chinese timezones
by Jesper Norgaard Welen July 10, 2006

July 10, 2006

The chinese timezones don't have much description in the tz database. I am currently trying to make a map of the worlds timezones base on the Olson database, and so I miss some more information about what these timezones cover. * Asia/Harbin seems to cover the Heilongjiang region, no less no more. * Asia/Chongqing is a city lying in the Sichuan province, which is huge, so does the timezone represent all of the province? * Asia/Urumqi covers the Xinjiang province, but represents a definition problem since Kashgar also lies in the far western part of this province, so what does timezone Asia/Kashgar represent? Asia/Urumqi timezone according to the comments in the 'asia' file also covers Tibet, which lies in the Xizang province, that is huge stretching from Kashmir to Myanmar, so I don't know if all of this is covered by the Asia/Urumqi timezone alone. * Asia/Shanghai covers all the rest of China as I understand it. This is the timezone there was recently a discussion about changing to Asia/Beijing, I believe. Can anyone shed some light on this? - Jesper Nørgaard Welen

7 12

Oshu tries "DST"; S. Korea considers DST; DST in S. Korea 1949-1961?
by Paul Eggert July 10, 2006

July 10, 2006

In South Korea the Ministry of Commerce, Industry and Energy has commissioned a research project to consider the reintroduction of daylight saving time as early as 2008. See the following articles: http://e.sinchew-i.com/content.phtml?sec=2&artid=200607080000 http://www.koreaherald.co.kr/SITE/data/html_dir/2006/07/10/200607100012.asp The first story says "Korea had a daylight saving program from 1949-61, and again in 1987-88." The second story, by Annie I. Bang, gives a bit more detail: "Korea ran a daylight saving program from 1949-61 but stopped it during the 1950-53 Korean War." We have the 1987-1988 records, but for the earlier period our current database has South Korea observing DST only from May 15 through September 12, 1960. This is from Shanks & Pottenger. If anyone has more detailed info please let me know. A July 3 UPI story reports that citizens of Oshu, Japan set their clocks forward on June 21. They'll move them back August 11. This appears to be an experiment by the local chamber of commerce to get people to go to work an hour earlier, and come home an hour earlier, as part of the "Cool Biz" no-tie, no-jacket campaign that the Japanese environment ministry has been promoting lately. About 50 businesses are changing their clocks, but it does not appear to affect anyone else. Another part of the compaign sets air conditioning thermostats to 28 degrees Celsius at workplaces. Hokkaido has been doing something similar since 2004. Here are references: http://www.upi.com/NewsTrack/view.php?StoryID=20060703-070848-4585r http://www.yomiuri.co.jp/dy/national/20060703TDY09003.htm

1 0

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