- tz - lists.iana.org

problem with tz mailling list?
by Paul Eggert Dec. 18, 1997

Dec. 18, 1997

I got the following bounce message from elsie.nci.nih.gov; is there some problem with the tz mailing list? ------- Start of forwarded message ------- Return-Path: <Mailer-Daemon(a)elsie.nci.nih.gov> Received: from red.twinsun.com (red-office.twinsun.com [192.54.239.70]) by tattoo (SMI-8.6/SMI-SVR4) with SMTP id LAA06184 for <eggert@tattoo>; Thu, 18 Dec 1997 11:32:55 -0800 Received: from alcor.twinsun.com (alcor.twinsun.com [198.147.65.9]) by red.twinsun.com (SMI-8.6/SMI-SVR4) with SMTP id LAA14437 for <eggert(a)twinsun.com>; Thu, 18 Dec 1997 11:32:55 -0800 Received: from elsie.nci.nih.gov (elsie.nci.nih.gov [165.112.73.1]) by alcor.twinsun.com (8.8.5/8.7.3) with SMTP id LAA29057 for <eggert(a)twinsun.com>; Thu, 18 Dec 1997 11:28:36 -0800 (PST) Received: by elsie.nci.nih.gov (4.1/SMI-4.1) id AB06282; Thu, 18 Dec 97 14:33:19 EST Date: Thu, 18 Dec 97 14:33:19 EST From: Mailer-Daemon(a)elsie.nci.nih.gov (Mail Delivery Subsystem) Subject: Returned mail: Service unavailable Message-Id: <9712181933.AB06282(a)elsie.nci.nih.gov> To: <eggert(a)twinsun.com> Content-Length: 3491 Status: ----- Transcript of session follows ----- <<< HELO alcor.twinsun.com <<< MAIL From:<eggert(a)twinsun.com> <<< RCPT To:<tz(a)elsie.nci.nih.gov> <<< DATA <<< QUIT Cannot exec '/usr/local/etc/smrsh' errno=2 554 "|exec /mnt/ado/slist/.bin/flist tz"... Service unavailable 554 "|exec /mnt/ado/slist/.bin/flist tz"... Service unavailable ----- Unsent message follows ----- Return-Path: <eggert(a)twinsun.com> Received: from alcor.twinsun.com by elsie.nci.nih.gov (4.1/SMI-4.1) id AA06280; Thu, 18 Dec 97 14:33:19 EST Received: from red.twinsun.com ([192.54.239.70]) by alcor.twinsun.com (8.8.5/8.7.3) with SMTP id LAA29052; Thu, 18 Dec 1997 11:27:54 -0800 (PST) Received: from shade.twinsun.com (shade.twinsun.com [192.54.239.27]) by red.twinsun.com (SMI-8.6/SMI-SVR4) with SMTP id LAA14404; Thu, 18 Dec 1997 11:32:06 -0800 Received: from (eggert@localhost) by shade.twinsun.com (SMI-8.6/SMI-SVR4) id LAA01366; Thu, 18 Dec 1997 11:31:47 -0800 Date: Thu, 18 Dec 1997 11:31:47 -0800 Message-Id: <199712181931.LAA01366(a)shade.twinsun.com> From: Paul Eggert <eggert(a)twinsun.com> To: bsawyer(a)mtnia.com Cc: tz(a)elsie.nci.nih.gov In-Reply-To: <9712181343.AA04768(a)elsie.nci.nih.gov> (OLSONA(a)dc37a.nci.nih.gov) Subject: Re: FW: "info about the world time zones" References: <9712181343.AA04768(a)elsie.nci.nih.gov> From: Brian Sawyer[SMTP:bsawyer@mtnia.com] Sent: Thursday, December 18, 1997 1:42 AM I'm wondering if you have any info about the world time zones, not by maps but numbers. example: Marshalltown, Iowa to Los Angelos -2 hours to New York +1 hour and so on. It's not as simple as that, since differences between cities vary with time. For example, during the summer Phoenix is two hours behind Marshalltown, but during the winter, it's only one hour behind. If you just want a simple listing with major cities, you can use the tz database at <ftp://elsie.nci.nih.gov/pub/>, using America/Chicago to represent Marshalltown (this should be valid for dates at least back to 1970). For example, here's a shell transcript to illustrate the current times in Marshalltown and Los Angeles. $ TZ=America/Chicago date # current time in Marshalltown: Thu Dec 18 13:26:06 CST 1997 $ TZ=America/Los_Angeles date # current time in Los Angeles: Thu Dec 18 11:26:06 PST 1997 If you're building a web site, this sort of thing can be easily done in a CGI script; see <http://www.bsdi.com/date> for an example of this. If you want more detailed listings, by far the best tabular source of historical time zone data that I know of are the following books, which contain location names and time zone histories for thousands of locations around the globe. They will tell you more about Marshalltown's time zone history than you probably know yourself. Thomas G. Shanks, The American Atlas (5th edition), San Diego: ACS Publications, Inc. (1991). Thomas G. Shanks, The International Atlas (4th edition), San Diego: ACS Publications, Inc. (1995). [This covers places outside the United States.] A good source for detailed recent time zone data is the International Air Transport Association's Standard Schedules Information Manual (IATA SSIM), published semiannually. However, this is considerably more expensive than Shanks, and it covers only airports, whereas Shanks covers more burgs and hamlets than even my Rand McNally atlas does, and does an excellent job for most places in the US (though even he throws up his hands at the time zone history of Indiana). ------- End of forwarded message -------

1 0

FW: "info about the world time zones"
by Olson, Arthur David Dec. 18, 1997

Dec. 18, 1997

---------- From: Brian Sawyer[SMTP:bsawyer@mtnia.com] Sent: Thursday, December 18, 1997 1:42 AM To: tz(a)elsie.nci.nih.gov Subject: I would like to be on your mailing list. I'm wondering if you have any info about the world time zones, not by maps but numbers. example: Marshalltown, Iowa to Los Angelos -2 hours to New York +1 hour and so on. I'm looking for conversions to cities around the world. If you know of a list like this some where, email me back. I can't see the maps very well to see what time it is in another part of the world. I really would like a listing of cities and a + or - hours with them. I hope you can help me out. Thanks for your cooperation and you have a joyous and peaceful holiday season. Sincerely, Brian Sawyer

2 1

I would like to be on your mailing list.
by Brian Sawyer Dec. 18, 1997

Dec. 18, 1997

I'm wondering if you have any info about the world time zones, not by maps but numbers. example: Marshalltown, Iowa to Los Angelos -2 hours to New York +1 hour and so on. I'm looking for conversions to cities around the world. If you know of a list like this some where, email me back. I can't see the maps very well to see what time it is in another part of the world. I really would like a listing of cities and a + or - hours with them. I hope you can help me out. Thanks for your cooperation and you have a joyous and peaceful holiday season. Sincerely, Brian Sawyer

1 0

Re: Could you send me a listing of time zones of the world.
by Brian Sawyer Dec. 18, 1997

Dec. 18, 1997

stewart(a)parc.xerox.com wrote: > > In message <34976107.4451(a)mtnia.com> you write: > >Could you email me time zones of the world by plus or minus hours > >converted from the united states times to the other countries, not by > >just a map, but actually listing the city and then if it ahead or behind > >my time. An example would be: > >Marshalltown, Iowa (I'm from here) to Los Angelos -2 hours > > to New York +1 hour > >and so on with conversions from all over the world. > >I have poor eyes and can't see the maps very good. I'm interested in > >time. I thank you for your time and cooperation. You have a Merry > >Christmas and a Happy New Year. > > Merry christmas to you too. Since I don't have a way to do this offhand, > I'll give you a pointer to some information that will allow you to do this. > The folks who maintain the Timezone Database and the various access > routines have a mailing list at tz(a)elsie.nci.nih.gov. Current > versions of their database and access library live at > ftp://elsie.nci.nih.gov/pub. > > -- > Paul I was asked by Paul if I could refer to you on this matter. Can youhelp me out? Can I be on your mailing list. Contact me by email. Thank you for your cooperation and you have a very peaceful and joyous holiday season. Sincerely, Brian Sawyer

1 0

FW: Non Delivery Report
by Olson, Arthur David Dec. 10, 1997

Dec. 10, 1997

Note that Denis is not on the time zone list; you may want to include Denis in any replies. --ado ---------- From: Denis.Excoffier@ens.fr[SMTP:Denis.Excoffier@ens.fr] Sent: Wednesday, December 10, 1997 11:00 AM To: tz(a)elsie.nci.nih.gov Cc: Denis.Excoffier(a)ens.fr Subject: europe France 1891 Extracted from the "europe" file : # Shanks gives 0:09 for Paris Mean Time; go with Whitman's more precise 0:09:05. Should be 0:09:21 instead. By the way, is there somewhere a lastest version of those files ? Another question : my zdump seems to be broken (mentions 1970 too often). Ever heard about this ? (solaris2.5, sparc20) Have a nice day, Scof.

2 1

europe France 1891
by Denis.Excoffier＠ens.fr Dec. 10, 1997

Dec. 10, 1997

Extracted from the "europe" file : # Shanks gives 0:09 for Paris Mean Time; go with Whitman's more precise 0:09:05. Should be 0:09:21 instead. By the way, is there somewhere a lastest version of those files ? Another question : my zdump seems to be broken (mentions 1970 too often). Ever heard about this ? (solaris2.5, sparc20) Have a nice day, Scof.

1 0

Timezone settings for rarotonga wrong.
by Alan Brown Dec. 2, 1997

Dec. 2, 1997

This may have already been corrected. Rarotonga stopped using Daylight Savings Time at least 6 years ago, probably 8 years ago. It's tropical, so there's no sense in them using it. Daylight savngs was used to keep them in sync with New Zealand's daylight savings changes. (Rarotonga is the main island of the Cook Islands - a self-governing state in free association with New Zealand) It's also 10 hours behind GMT/UTC, not ahead of it. Regards Alan Brown.

1 0

FW: Time zone data
by Olson, Arthur David Dec. 1, 1997

Dec. 1, 1997

Charlie Hendricksen is not on the time zone list; please be sure that Charlie is included in any replies. --ado ---------- From: Charlie Hendricksen[SMTP:veritas@u.washington.edu] Sent: Thursday, November 27, 1997 2:58 PM To: ao1d(a)nih.gov Subject: Time zone data Mr. Olson, I found a reference to your timezone work in Bill Thoen's page. I poked around in the ftp server and noticed five files, all nice and big! I experienced difficulty in extracting the tzarchive.gz. so I thought I would contact you before trying any of the other files. I am interested in obtaining a file of the geocoded boundaries of the time zones. I realize that time zones are marvelously complex and frequently changing, so I don't expect perfection. Since I have access to Arc/Info, I prefer the GIS approach to laborious entry of data into a spreadsheet. Can you steer me in the right direction? -- Charlie Hendricksen veritas(a)u.washington.edu

1 0

Happy Leap Second!
by Chris Newman Nov. 24, 1997

Nov. 24, 1997

I hope everyone enjoys their extra second! This also serves as a test to see what really happens if there is a "60" for seconds in the date header. - Chris

3 3

Please help with general info
by Mark Halliday Nov. 22, 1997

Nov. 22, 1997

Hi. I'm working on a project that requires rendering historical data with gmt timestamps in various local timezones. I found this email address in the "europe" file in the glibc-2.0.5\time directory. Can you point me to an overview of the files in this directory, or any other timezone conversion documentation? Who is responsible for maintaining the tables and code is this directory? The Readme file refers to "tzdata1997a package by Arthur David Olsen et.al." I couldn't find any info about this package in the gnu ftp tree. Any help is appreciated. Thanks in advance, Mark # @(#)europe 7.45 # This data is by no means authoritative; if you think you know better, # go ahead and edit the file (and please send any changes to # tz(a)elsie.nci.nih.gov for general use in the future).

1 0

FW: 32-bit 2038 issue
by Olson, Arthur David Nov. 21, 1997

Nov. 21, 1997

> > changing time_t to an unsigned int would give another 68 years > But that would break backward compatibility with many applications. > Few vendors have gone to an unsigned time_t (in fact, I don't know of > any offhand) and there are good reasons for this. A possibility would be to interpret the values in time zone files as unsigned WITHOUT changing the type of time_t. --ado

2 1

beta versions of time zone stuff
by Olson, Arthur David Nov. 20, 1997

Nov. 20, 1997

The files ftp://elsie.nci.nih.gov/pub/tzcodebeta.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdatabeta.tar.gz are now available. 1. zic puts "TZif" at the start of each file it outputs. 2. zic looks for lines of the form #Updated Zone America/New_York 1997 Nov 19 17:58:00 and #Updated Rule NYC 1997 Nov 19 17:58:00 and, when generating output for a zone, stamps the output with the greatest "Updated" time for the zone or any of the rules it uses. Comments heartily solicited! --ado

1 0

Request
by Gatsometer Nov. 17, 1997

Nov. 17, 1997

Hello everyone, I am Peter Smit and working for Gatsometer Holland in R&D. Our equipment for traffic control is exported all over the world. I am looking for some data base or algorithm that produces GMT offset or TZ name if longitude and latitude are input from GPS. Perhaps any of you know someone or an institute that can help. I have taked a look at ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz already and found there the file zone.tab. But maybe someone knows some other stuff. Thanks for your response. Regards, Peter Smit

1 0

`AET' vs `GST' for time in United Arab Emirates
by Paul Eggert Nov. 12, 1997

Nov. 12, 1997

In <news:641quc$182@t1.emirates.net.ae> (1997-11-08), framness(a)EMIRATES.NET.AE (Mark Framness) writes that he uses AET as a string that he made up for ``Arab Emirates Time''. Currently the tz database at ftp://elsie.nci.nih.gov/pub/ uses `GST' for the Persian Gulf states, but that was an abbreviation that I invented from whole cloth, and this news posting suggests that the tz database should use ISO country codes instead for the Persian Gulf area. Similarly for `AST/ADT' for Arabia Standard/Daylight Time. Comments?

1 0

Re: 32-bit 2038 issue
by Joel.Tornatore＠Eng.Sun.COM Nov. 11, 1997

Nov. 11, 1997

changing time_t to an unsigned int would give another 68 years without any of the size/performance problems mentioned in Tom's email. joel ## From tomp(a)zk3.dec.com Tue Nov 11 12:40:27 1997 ## Old-Return-Path: <tomp(a)zk3.dec.com> ## To: tz(a)elsie.nci.nih.gov ## Cc: Tom Peterson <tomp(a)zk3.dec.com>, simons(a)zk3.dec.com, dlong(a)zk3.dec.com ## Subject: 32-bit 2038 issue ## X-Mts: smtp ## ## ## Has anyone considered what to do about time zone files and the 32-bit 2038 ## issue? This comment from zic.c sums up the problem: ## ## > /* ## > ** The tz file format currently allows at most 32-bit quantities. ## > ** This restriction should be removed before signed 32-bit values ## > ** wrap around in 2038, but unfortunately this will require a ## > ** change to the tz file format. ## > */ ## ## With Y2K bringing attention to time-related problems, there's an increasing ## awareness/concern about the 2038 issue as well. People know it's not just a ## system clock setting issue. The limitations affect projected dates used by ## applications as well. Problems are already cropping up where financial ## institutions can't generate amortization data for 40, 50, etc year loans and ## the like. I expect there are other practical examples as well. ## ## As new 64-bit UNIX platforms are emerging, there's a trend toward 64-bit ## time_t's. While this certainly eliminates the 2038 limit, it also creates a ## problem for time zone data files. A time zone file filled with data spanning ## 64-bits of seconds-based time would be huge, not to mention the performance ## problems of accessing it. Some ideas for addressing this problem are: ## ## 1) Expand the date/time boundaries for time zone files to a specific range. ## This would have to balance file size vs anticipated application needs. ## Perhaps an upper limit corresponding to the year 2100 or 2200 would suffice? ## Regardless of the range set, this approach only delays the problem. ## ## 2) Find some way to mimic what the zic compiler does at run-time. This might ## involve generating some kind of algorithmic data for each time zone which can ## be used to calculate future transition times, etc on-the-fly. I'm not sure ## this is possible or practical given the varied complexity of time zone rules. ## ## 3) Other ideas??? ## ## Also, with 64-bit time_t's, the tm struct becomes the limiting factor. ## Boundary checks now become an issue for localtime()/gmtime() instead of ## mktime(). This is a problem for standards at a mininum. While mktime() has ## the (somewhat ambiguous) -1 return value for non-representable times, no such ## provision is defined for localtime()/gmtime(). ## ## Any ideas or precedent for addressing this issue? ## ## thanks, ## - Tom ## ## ===================================================================== ## Tom Peterson | DIGITAL UNIX Development Environment ## Digital Equipment Corporation | Phone: (603) 884-7550 ## 110 Spit Brook Road ZKO3-2/W17 | FAX: (603) 884-2257 ## Nashua, NH 03062-2698 | Email: mailto:tomp@zk3.dec.com ## ## ##

2 1

Re: 32-bit 2038 issue
by Robert Elz Nov. 11, 1997

Nov. 11, 1997

Date: Tue, 11 Nov 1997 13:50:33 -0800 From: Joel.Tornatore(a)Eng.Sun.COM (Joel Tornatore) Message-ID: <199711112150.NAA26831(a)gap.eng.sun.com> | changing time_t to an unsigned int would give another | 68 years without any of the size/performance problems | mentioned in Tom's email. I made that change back in pre 4.2 bsd days. It turned out that it broke too much - most notably, programs that like to print ctime(0) (and there I mean the time_t with a value of 0, I know ctime really takes a pointed to a time_t, and ctime(0) would be a null pointer). The standard behaviour, anywhere west of Greenwich, was to not print Dec 31 1969 in that case, but some time way into the future, which was not at all what anyone expected. So, before 4.2 was actually released, time_t went back signed again. It was all this that caused some of the time functions able to adapt and work whether time_t turns out to be signed or not. kre

1 0

32-bit 2038 issue
by Tom Peterson Nov. 11, 1997

Nov. 11, 1997

Has anyone considered what to do about time zone files and the 32-bit 2038 issue? This comment from zic.c sums up the problem: > /* > ** The tz file format currently allows at most 32-bit quantities. > ** This restriction should be removed before signed 32-bit values > ** wrap around in 2038, but unfortunately this will require a > ** change to the tz file format. > */ With Y2K bringing attention to time-related problems, there's an increasing awareness/concern about the 2038 issue as well. People know it's not just a system clock setting issue. The limitations affect projected dates used by applications as well. Problems are already cropping up where financial institutions can't generate amortization data for 40, 50, etc year loans and the like. I expect there are other practical examples as well. As new 64-bit UNIX platforms are emerging, there's a trend toward 64-bit time_t's. While this certainly eliminates the 2038 limit, it also creates a problem for time zone data files. A time zone file filled with data spanning 64-bits of seconds-based time would be huge, not to mention the performance problems of accessing it. Some ideas for addressing this problem are: 1) Expand the date/time boundaries for time zone files to a specific range. This would have to balance file size vs anticipated application needs. Perhaps an upper limit corresponding to the year 2100 or 2200 would suffice? Regardless of the range set, this approach only delays the problem. 2) Find some way to mimic what the zic compiler does at run-time. This might involve generating some kind of algorithmic data for each time zone which can be used to calculate future transition times, etc on-the-fly. I'm not sure this is possible or practical given the varied complexity of time zone rules. 3) Other ideas??? Also, with 64-bit time_t's, the tm struct becomes the limiting factor. Boundary checks now become an issue for localtime()/gmtime() instead of mktime(). This is a problem for standards at a mininum. While mktime() has the (somewhat ambiguous) -1 return value for non-representable times, no such provision is defined for localtime()/gmtime(). Any ideas or precedent for addressing this issue? thanks, - Tom ===================================================================== Tom Peterson | DIGITAL UNIX Development Environment Digital Equipment Corporation | Phone: (603) 884-7550 110 Spit Brook Road ZKO3-2/W17 | FAX: (603) 884-2257 Nashua, NH 03062-2698 | Email: mailto:tomp@zk3.dec.com

2 1

request!
by Gatsometer Nov. 11, 1997

Nov. 11, 1997

Hello everyone, I am Peter Smit and working for Gatsometer Holland in R&D. Our equipment for traffic control is exported all over the world. I am looking for some data base or algorithm that produces GMT offset or TZ name if longitude and latitude are input from GPS. Perhaps you know someone or an institute that can help. I have already take a look at ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz and found there the file zone.tab. Thanks for your response. Regards, Peter Smit

1 0

Re: Time stamp(s)
by ncm＠cantrip.org Nov. 3, 1997

Nov. 3, 1997

Paul Eggert <eggert(a)twinsun.com> wrote: > From: "Olson, Arthur David" <OLSONA(a)dc37a.nci.nih.gov> > > my guess is that the thing to do is put at the start of the file a > count of the number of bytes worth of stamp that appear, then put > the stamp information itself at the end of the file. > > How would this work with the Unix `file' command? Mr. Eggert's posting seems to confuse two independent improvements: a file magic number and a set of validity timestamps. Of course any "record offset" for the timestamps would come after the magic number. I agree with Mr. Olson that it would be better not to use up all the remaining uncommitted bytes in the record for timestamps, and that placing the offset to such a record elsewhere in the file would be better. Nathan

1 0

Time stamp(s)
by Olson, Arthur David Nov. 1, 1997

Nov. 1, 1997

Whatever number of stamps end up in the file, my guess is that the thing to do is put at the start of the file a count of the number of bytes worth of stamp that appear, then put the stamp information itself at the end of the file. This minimizes the encroachment on the twenty remaining bytes of "reserved for future use" space; it also would allow us to have longish, easy-for-humans-to-read stamp information (either in addition to or instead of shorter, easy-for-computers-to-process information). My sense is that one stamp might be sufficient. A client picking up time zone information from multiple sources would use the one with the largest stamp. The stamp might be automatically generated as a function of the maximum "until" time appearing on a "Zone" line for the zone in question and the maximum "from" and "to" years appearing on a "Rule" line for the zone in question. Doing this would eliminate the need for separate maintenance of information from which to generate stamps; it would also avoid adding information to the zic input files that old versions of zic would not be able to handle. The down side would be that if we learned of a correction to zone information that only affected past times, we wouldn't get an *automatic* update of the stamp for the zone. Comments? --ado

2 1

Proposed DST change for Sydney Olympics
by Eric Ulevik Oct. 26, 1997

Oct. 26, 1997

SOCOG (the Sydney Organizing Commitee for the Olympic Games) have requested that daylight savings time start early in 2000, to make things easier when running the games. The proposed start date is 27 August 2000. This would mean Sydney having eight months of daylight savings time. Apparently the NSW Government is looking favourably on this proposal. Regards, Eric Ulevik Reference: Sunday Telegraph, 26 October 1997, page 26

1 0

News from the UK
by peter＠aldie.co.uk Oct. 25, 1997

Oct. 25, 1997

The Independent (one of the quality broadsheet papers over here) has a piece today (25 Oct) about the clock change tomorrow morning. It can be found at http://www.independent.co.uk/stories/A2510709.html. The short summary: John Butterfill won't be having another go at changing the law. He doesn't know of any other MP who will try. The Home Office say the government has no plans to legislate either. The only other recent thing of relevence I have seen is that a tiny footnote in the White Paper on Scottish Devolution said that `the regulation of time zones' was one of the things that would be reserved to Westminster and wouldn't be devolved. The White Paper is at http://www.scottish-devolution.org.uk/white%20paper/papercon.htm with the footnote being in Chapter 3. Peter Ilieve peter(a)aldie.co.uk

1 0

FW: Time Zone Data File Conventions
by Olson, Arthur David Oct. 17, 1997

Oct. 17, 1997

(Note that wally.wedel(a)central.sun.com is not on the time zone mailing list; be sure that a copy of any reply gets sent that way. --ado.) ---------- From: Waldo (Wally) Wedel [Sun Professional Services JDC][SMTP:wally.wedel@Central.Sun.COM] Sent: Wednesday, October 15, 1997 4:52 PM To: tz(a)elsie.nci.nih.gov Subject: Time Zone Data File Conventions Gentlemen: I am just finishing up implementing some general time zone classes in Java. I parse your data files and build time zone classes from them. Consequently, I have a few questions. 1) You use the concepts of "wall clock", "standard", and "GMT" time in specifying transition times. I'd like to verify just what these mean. a) Does "wall clock" mean simply take the time as given applying no corrections? b) Does "standard" mean apply DST time shift to given time to find true time? c) Does "GMT" mean apply GMT offset to given time to get true time? 2) Is the convention for rule naming that when searching for the applicable rule, one looks for a rule with the specified name covering the specified date? I assume that failure to find a rule implies no time shift. 3) The comments in the data files contain quite important information about the actual coded information. Have you considered converting them to HTML to get them better tagged? I'm particularly interested in tagging some kind of a long name usable in reports and like. I've been trying to figure out how to preserve them in an OODB so that they are properly associated with the data they describe. Thanks for any help you can provide. -- Wally Wedel Wally.Wedel(a)sun.com SunService Division (303) 804-3073 Java Design Center Fax: (303) 290-1696 5251 S DTC Parkway Englewood, CO 80111-2700

5 5

FW: Time zone in Atikokan, Ontario, Canada
by Olson, Arthur David Oct. 17, 1997

Oct. 17, 1997

---------- From: msb@sq.com[SMTP:msb@sq.com] Sent: Wednesday, October 15, 1997 2:09 AM To: ado(a)elsie.nci.nih.gov Cc: eggert(a)twinsun.com Subject: Time zone in Atikokan, Ontario, Canada If I look at my road atlases, I see a nice straight-line boundary between Eastern and Central Time in Ontario, following the 90th west meridian from the boundary with Manitoba to that with Minnesota. Atikokan is located about 80 miles west of the 90th meridian and about 120 miles west of Thunder Bay. Article in the Toronto Star, 1997-10-14: | Atikokan asked to vote on daylight savings time | | ATIKOKAN (CP) -- Voters here are being asked to decide | what time it should be. | | Like Saskatchewan, this northwestern Ontario community | of 4,000 does not change to daylight savings time. | | That means clocks are an hour behind the rest of the | province in the summer months. | | The chamber of commerce wants the town on eastern time | year-round because it says most of the community's | business dealings are with clients in that region. | | The question will be on the ballot in the Nov. 10 | municipal election. Presumably this means that (1) either the Canadian Press or the Toronto Star is unaware that not all of Ontario observes Eastern Time, and (2) Atikokan has been been observing UTC-5 = Eastern Standard Time = Central Daylight Time all year, and now proposes to move to Eastern Time. I thought the tz mailing list might be interested, if they hadn't already heard. I'm afraid I have no idea which level of government has official jurisdiction on the question here.

2 1

Time Zone Data File Conventions
by Waldo (Wally) Wedel [Sun Professional Services JDC] Oct. 15, 1997

Oct. 15, 1997

Gentlemen: I am just finishing up implementing some general time zone classes in Java. I parse your data files and build time zone classes from them. Consequently, I have a few questions. 1) You use the concepts of "wall clock", "standard", and "GMT" time in specifying transition times. I'd like to verify just what these mean. a) Does "wall clock" mean simply take the time as given applying no corrections? b) Does "standard" mean apply DST time shift to given time to find true time? c) Does "GMT" mean apply GMT offset to given time to get true time? 2) Is the convention for rule naming that when searching for the applicable rule, one looks for a rule with the specified name covering the specified date? I assume that failure to find a rule implies no time shift. 3) The comments in the data files contain quite important information about the actual coded information. Have you considered converting them to HTML to get them better tagged? I'm particularly interested in tagging some kind of a long name usable in reports and like. I've been trying to figure out how to preserve them in an OODB so that they are properly associated with the data they describe. Thanks for any help you can provide. -- Wally Wedel Wally.Wedel(a)sun.com SunService Division (303) 804-3073 Java Design Center Fax: (303) 290-1696 5251 S DTC Parkway Englewood, CO 80111-2700

1 0