- tz - lists.iana.org

hello
by JReinh7904＠aol.com June 14, 2000

June 14, 2000

To whom it may concern, My computer is on Pacific daylight savings time and I don't know how to change it to Eastern Time can you please help me out. Yours truely, Jen

1 0

Re: ACS Atlas
by Paul Eggert June 13, 2000

June 13, 2000

From: "Jamie" <jamie(a)maxnet-usa.net> Date: Sun, 11 Jun 2000 22:09:23 -0400 Doris Chase Doane has a book out on Time Changes through out the world. I just downloaded your timezone information from the ftp.btx.com site and noticed that it doesn't seem like you really have very much information. The tz database concentrates on time changes since 1970, for two reasons. First, the tz code is based on the POSIX.1 computer standard, and portable POSIX.1 time stamps cannot occur before 1970. Second, it makes the database a lot smaller if we partition the world only into locations whose time histories differ since 1970, and ignore any extra partitioning due to earlier differences. It'd be nice if someone extended the tz database backward in time to all known time stamp histories, but that would be a lot of work and nobody has done it (yet). I'm trying to create an atlas that provides the correct time zone based upon not just the date but the town and place. If you find errors in the tz database, please send email to <tz(a)elsie.nci.nih.gov>. For more complete coverage of dates before 1970, I recommend Shanks's time zone history atlases. They do not always agree with Doane, but they seem to be popular among astrologers these days. Please see: http://www.astro.com/atlas/index.html http://astrocom.com/software/ACS_PC_Atlas.htm http://astrocom.com/books/xrefa.htm#SHANKS there are frequently situations where the uncertainty about the time was actually the norm rather than the rule. You're quite right. For example, what was the time zone of Wise, Virginia on October 18, 1927? According to <http://www.astrodatabank.com/NMScottGeorgeC.htm>, Doane and Shanks disagree and in this case Doane's probably correct. Or, to take a modern example, what is the time zone of Pangnirntung, Nunavut, Canada? The province disagrees with the city, so city and commercial offices operate in one time zone and provincial offices operate on another. (How will your database address problems like Pangnirtung's?)

2 1

Timezone in Iraqi Kurdistan
by Jonathan Lennox June 12, 2000

June 12, 2000

An article in this week's Economist ("Inside the Saddam-free zone", p. 50 in the U.S. edition) on the Iraqi Kurds contains a paragraph: "With help from the UN, and protected by an air shield provided by America and Britain, the three northern provinces, although officially part of Iraq, have become the de facto state of Kurdistan, enjoying far more autonomy than the Kurds in Turkey, Iran or Syria. They use a different currency and patrol their own borders. They even switched their clocks this spring and are an hour ahead of Baghdad." Anyone know anything more about this? tzdata2000d only has a single entry for Iraq, Asia/Baghdad. -- Jonathan Lennox lennox(a)cs.columbia.edu --KAA03013.960821760/cs.columbia.edu--

2 1

Re: Electronic Shanks
by apritchard＠cix.co.uk June 12, 2000

June 12, 2000

Is the data exportable from this, does anyone know? Best wishes Alan Pritchard The GLOBAL GAZETTEER: the world on file http://www.allm-geodata.com Tel: +44 (0) 1202 417 477

1 0

Re: Java zoneinfo reader
by Paul Eggert June 7, 2000

June 7, 2000

Date: Wed, 07 Jun 2000 12:56:30 -0400 From: "Stuart D. Gathman" <stuart(a)bmsi.com> I had an elegant idea which is unfortunately incompatible with current tz format. Instead of transition times for *offsets*, the history should store transition times for *algorithms*. Yes, that's a more obvious idea, and it's probably a better one as it'll be easier to explain. (Might as well switch to XML while we're at it. :-) But I don't see why you think it's any more compatible with the current tz format than the other ideas we've talked about. All the ideas will require changes to the compiled tz files; these changes can and should be installed in a way that does not break old applications, either by installing a completely new set of tz files, or by employing unused fields in the old files.

1 0

Re: FW: Java zoneinfo reader
by Paul Eggert June 6, 2000

June 6, 2000

Date: Tue, 06 Jun 2000 18:45:29 -0400 From: "Stuart D. Gathman" <stuart(a)bmsi.com> zic would add extra "transitions" (with the same offset) when transitions are more than 2**32 secs apart. Think of it as 64 bit values with differential compression. Good point; didn't think of that. However, how would this address C code like the following? time_t t = 60000000000000000; struct tm *tm = gmtime (&t); This yields a time stamp in the year 1901324310. We can't store a table of all the transitions until then -- that'd take too much space. So if we want to handle extreme examples like this, we need an algorithmic prediction of future transitions. I realize that any prediction of future transitions will be incorrect, but the most useful prediction in practice is to use the current rules, and it'd be nice if we could support this into the indefinite future, at least for the common cases. Here's an idea. All the current tz rules are rational, in the sense that the pattern of transitions repeats after a while. So if we could append a "go back N transitions" instruction at the end of the compiled tz file, a compiled tz file could represent any set of planned transitions that a tz input file can represent.

1 0

FW: Java zoneinfo reader
by Olson, Arthur David (NCI) June 6, 2000

June 6, 2000

Stuart is not on the time zone mailing list; be sure to direct replies appropriately. --ado > -----Original Message----- > From: Stuart D. Gathman [SMTP:stuart@bmsi.com] > Sent: Thursday, June 01, 2000 5:11 PM > To: tz(a)elsie.nci.nih.gov > Subject: Java zoneinfo reader > > I have a Java implementation of java.util.TimeZone that reads the > /etc/zoneinfo database. It is not yet 2038 compliant - I propose a > solution in the docs. I will browse your site to see if the zoneinfo > database handles 2038 yet. > > http://www.bmsi.com/java/#TZ

3 3

FW: Longitute/Latitute to TIME zone
by Olson, Arthur David (NCI) June 6, 2000

June 6, 2000

Muhammad is not on the time zone mailing list; be sure to direct any replies appropriately. --ado > -----Original Message----- > From: Muhammad Safeer [SMTP:msafeer@khi.compol.com] > Sent: Thursday, June 01, 2000 7:47 AM > To: tz(a)elsie.nci.nih.gov > Subject: Longitute/Latitute to TIME zone > > Is there any formula to convert Longitute/Heading to time zone. > > Regards. > > Muhammad Safeer.

3 3

Java zoneinfo reader
by Stuart D. Gathman June 1, 2000

June 1, 2000

I have a Java implementation of java.util.TimeZone that reads the /etc/zoneinfo database. It is not yet 2038 compliant - I propose a solution in the docs. I will browse your site to see if the zoneinfo database handles 2038 yet. http://www.bmsi.com/java/#TZ

1 0

Lat/long -> time zone
by apritchard＠cix.co.uk June 1, 2000

June 1, 2000

Dear Muhammed Safeer As far as I am able to determine, there is no general formula to determine time zone from lat/long. We are able to use certain rules in the Global Gazetteer, and keep time zone information in a variety of ways. In the end, though it is necessary to code places by hand. The hierarchy that I use goes as follows: 1. The whole of a country keeps to the same time zone, e.g. UK 2. The country is split into different time zones, but it is possible to assign time zone via administrative level 1 (e.g. Spain). 3. Some administrative level 1s are split themselves into different time zones, but lower level administrative areas fall into the different time zones (e.g. US counties) 4. Finally, there are some areas where there appears to be no obvious way in which admin. areas can be used to determine time zones, although this may be due to my lack of knowledge and/or data. E.g. the Broken Hill area in Australia. It is at this level that I code these by hand and assign the correct zone. HTH Best wishes Alan Pritchard The GLOBAL GAZETTEER: the world on file http://www.allm-geodata.com Tel: +44 (0) 1202 417 477 > Muhammad is not on the time zone mailing list; be sure to direct any > replies > appropriately. > > --ado > > > -----Original Message----- > > From: Muhammad Safeer [SMTP:msafeer@khi.compol.com] > > Sent: Thursday, June 01, 2000 7:47 AM > > To: tz(a)elsie.nci.nih.gov > > Subject: Longitute/Latitute to TIME zone > > > > Is there any formula to convert Longitute/Heading to time zone. > > > > Regards. > > > > Muhammad Safeer. >

1 0

Longitute/Latitute to TIME zone
by Muhammad Safeer June 1, 2000

June 1, 2000

Is there any formula to convert Longitute/Heading to time zone. Regards. Muhammad Safeer.

1 0

timezone database
by Max Hodges May 30, 2000

May 30, 2000

I'm trying to download the timezone databaes from ftp://elsie.nci.nih.gov/pub/ from I'm getting timeout errors. Has this address changed or is the server down, or am I having some other problem? Thanks! Max Hodges Houston, Texas

1 0

Passage on 1916 Summer Time Bill
by Joseph S. Myers May 18, 2000

May 18, 2000

Today's The Times reprints an item from 1916 on the Summer Time Bill, 1916. http://www.the-times.co.uk/news/pages/tim/2000/05/18/x-timcrtcrt01011.html -- Joseph S. Myers jsm28(a)cam.ac.uk

1 0

Time Zone App Beta
by Andre-Tascha Lamme May 17, 2000

May 17, 2000

Hey all... A few days away from completing a Windows (32bit) app and accompanying ActiveX control for time zone stuff Need some testers to trash it for me. Please send me an email (andre-tascha.lamme(a)ironriver.com) if interested. (Let me know if you want the control or the app) Basic specs on the app/ActiveX: - Have approximately 28,000 locations (cities, etc.) - Each location is based on a Region (e.g. Asia), Country (ISO3166-1) and a Country's regional info (ISO3166-2) if applicable. Each location has GMTOffset and standard DST info (if observes, the dates and amounts of offset). - In the app, one can browse or search through locations and add them to actives (i.e. for display). - Can add new locations (still debating whether or not I want to deal with allowing folks to send me their additions). - Can add people identifiers and assign them to existing locations. (Allows you to see what time it is where "Aunt Mathilda" is, rather than just generic "Providence, Rhode Island"). - Can set alarms/reminders to go off as of the specified time for a target location (i.e. Aunt Mathilda wants you to call her at 15:00 her time) - Any other suggestions? thanks... Andre'-Tascha

2 2

FW: Time Zone Codes
by Olson, Arthur David (NCI) May 17, 2000

May 17, 2000

Denis Spencer is not on the time zone mailing list; direct replies appropriately. --ado > -----Original Message----- > From: Spencer, Denis [OCDFR] [SMTP:dspencer@ocdfr.jnj.com] > Sent: Wednesday, May 17, 2000 5:07 AM > To: tz(a)elsie.nci.nih.gov > Subject: Time Zone Codes > > Are there any standards (like ISAO country codes) for time zones? > eg we use GMT = Greenwich Mean Time > CTE = Central European Time > EST = Eastern Standard Time > But we need others.

2 1

Time Zone Codes
by Spencer, Denis [OCDFR] May 17, 2000

May 17, 2000

Are there any standards (like ISAO country codes) for time zones? eg we use GMT = Greenwich Mean Time CTE = Central European Time EST = Eastern Standard Time But we need others.

1 0

webmaster
by ralphc＠worldskyline.com May 6, 2000

May 6, 2000

We would like to discuss a partnership that would involve building a web page to drive traffic to our site on a commission basis. Please reply or call Mr. Fardo at 1-800-635-6268.

1 0

Electronic Shanks
by Olson, Arthur David (NCI) April 28, 2000

April 28, 2000

The Shanks references are now evidently available in electronic form; see http://www.astrocom.com/software/ACS_PC_Atlas.htm If anyone on the list has experience with the packages, folks on the time zone list might appreciate insights. --ado

1 0

(no subject)
by Darryl Lane April 26, 2000

April 26, 2000

Hello there! My sister asked me to do a search for her and in an around about way it led me to your site. She is looking for a software program (or chart) that will allow her to know the 'actual time' of a person's birth as compared to if they were in a time zone that implemented war time or daylight savings time or some other such localized time difference in effect at the time of there birth.. She will use this to actualize any persons place/time of birth for her 'astrology' hobby. Can you help? Darryl Lane

1 0

tzcode2000d.tar.gz
by Olson, Arthur David (NCI) April 20, 2000

April 20, 2000

The file ftp://elsie.nci.nih.gov/pub/tzcode2000d.tar.gz is now available; tzdata2000d.tar.gz is unchanged. Included are changes to the documentation and code of strftime for C99 conformance, and a bug fix for date.c. These are based on (though modified from) the changes circulated on the time zone mailing list by Paul Eggert. I'll wait on changes to Argentina until the smoke clears. --ado

1 0

Formats of tz-data & docs
by Oscar van Vlijmen April 20, 2000

April 20, 2000

Just a couple of thoughts in the discussion regarding the formats of tz-data & docs. Maintainers and users of the excellent tz-code and -data: please note that you do not live in a UNIX-only world. There are some people who like to produce and already have produced timezone products, based on Windows applications, Mac OS applications and web interfaces. It seems not very useful and even difficult to compile or port the tz-code to other operating systems. The tz-data however is very useful to everybody. In my opinion the current format of the tz-data is OK and should not be changed. Every change in the format would mean that the parser had to be rewritten and rigorously tested. Too much trouble with hardly any gains at the moment; for UNIX users that is. Or am I missing something? The tz-data could however be formatted a bit more consistently. Sometimes the fields in Rule and Zone lines are separated by spaces, in most cases by tabs and sometimes by nothing more than a seemingly arbitrary field width. All field data should be consistently separated by tabs. This would enhance the 'importability' to other platforms. The documentation regarding the tz-data should be in a platform independent format. Non-UNIX users can do virtually nothing with the formats n/t/groff, Texinfo, DocBook, linuxdoc-sgml, whatever. One of the most useful formats at the moment would be HTML 4.0.1. In short I suggest: * Don't XML-ize or MIME-ize or VTIMEZONE-ize at the moment. * 'Make' or convert to HTML all documentation; to be added to the current groff docs. * Clean up the Zone & Rule formatted data. Oscar van Vlijmen 2000-04-20 In case of replies: please use my usual address o.van.vlijmen(a)tip.nl

1 0

RE: FW: Time Zone Issues
by Chris Sells April 20, 2000

April 20, 2000

The current format is *not* easily readable by machines unless all of the tzinfo parser accompanies the data. XML would allow the data to be used without the software, making it instantly available for all the platforms not supported today (I never did get the tzinfo parser to compile under Win32). XML parsers are far more commonly available than ports of the tzinfo parser software. > From: Eric Ulevik [mailto:eau@ozemail.com.au] ... > The downsides of XML are: > * you need a full up-to-date parser for most benefits You don't, actually. The tzinfo could be in the simpliest form of XML and still be extremely useful. > * right now, there are no good editors for creating XML Not true. Win32 has about half a dozen good ones. Check out xml.com for a large list of xml-related resources, including editors, for all platforms. Of course, the initial port of the XML should be generated by a program anyway, but for edits, you're right -- you'll need a good XML editor. > * data expands a fair bit That's true. Chris Sells http://staff.develop.com/csells > -----Original Message----- > From: Eric Ulevik [mailto:eau@ozemail.com.au] > Sent: Wednesday, April 19, 2000 2:47 PM > To: tz(a)elsie.nci.nih.gov > Cc: Garrett Wollman > Subject: Re: FW: Time Zone Issues > > > From: "Garrett Wollman" <wollman(a)khavrinen.lcs.mit.edu> > > <<On Tue, 18 Apr 2000 21:49:45 -0700 (PDT), Paul Eggert > <eggert(a)twinsun.com> said: > > > There has been talk from various quarters of XMLizing the whole > > > thing, but it would take some work and as far as I know nobody's > > > done it yet. > > And there is no inherent virtue in XML. The current format has the > > benefit that it is easily parsed by both machines and humans, which > > would be much more difficult in any XML-based scheme. > > The benefits of XML are: > * most computer systems will be able to directly read/write the structured > data > * guarantees validity of the data by the use of DTDs and Schemas > * handles internationalization properly > > The downsides of XML are: > * you need a full up-to-date parser for most benefits > * right now, there are no good editors for creating XML > * data expands a fair bit > > Regards, > > Eric Ulevik > >

3 3

Re: FW: Time Zone Issues
by Garrett Wollman April 19, 2000

April 19, 2000

<<On Thu, 20 Apr 2000 07:46:33 +1000, "Eric Ulevik" <eau(a)ozemail.com.au> said: > The downsides of XML are: > * you need a full up-to-date parser for most benefits > * right now, there are no good editors for creating XML > * data expands a fair bit * it's hard to grep -GAWollman

2 2

zic.8 in HTML format
by Oscar van Vlijmen April 19, 2000

April 19, 2000

Indeed, irritating if you don't have a nroff/troff reader and you would like to read the ".8" manual pages of the tz-code. I converted the zic.8 page from tzcode2000c to HTML format, completely by hand. I have no Unix/Linux OS, but I do have IBM's troff command manual page (308 KB). Everything after the separation line can be regarded as the HTML file in question. So copy those lines to a new text only file and name it "zic8.html" or something like that. If this doesn't work for you, I could send the HTML file as MIME-encoded mail-attachment. Anyhow, the HTML file looked fine in the browsers Netscape Navigator 4.7.2 and Microsoft Internet Explorer 4.5 in the Macintosh versions. I used no CSS (cascading style sheets) nor any fancy markup code, since there are still no browsers in existence that support all "standards". Please understand that my HTML conversion has NO OFFICIAL status. It should be regarded as an experiment; still useful though. Regards, Oscar van Vlijmen 2000-04-19 -------------------------------------------------------------------------- <html> <head> <title>ZIC 8 - time zone compiler</title> </head> <body> <h3>SYNOPSIS</h3> zic [ -v ] [ -d directory ] [ -l localtime ] [ -p posixrules ] [ -L leapsecondfilename ] [ -s ] [ -y command ] [ filename ... ] <h3>DESCRIPTION</h3> Zic reads text from the file(s) named on the command line and creates the time conversion information files specified in this input. If a filename is -, the standard input is read. These options are available: <dl> <dt>-d directory <dd>Create time conversion information files in the named directory rather than in the standard directory named below. <dt>-l timezone <dd>Use the given time zone as local time. Zic will act as if the input contained a link line of the form: <table><tr><td>Link<td>timezone<td>localtime</table> <dt>-p timezone <dd>Use the given time zone's rules when handling POSIX-format time zone environment variables. Zic will act as if the input contained a link line of the form: <table><tr><td>Link<td>timezone<td>posixrules</table> <dt>-L leapsecondfilename <dd>Read leap second information from the file with the given name. If this option is not used, no leap second information appears in output files. <dt>-v <dd>Complain if a year that appears in a data file is outside the range of years representable by time (2) values. <dt>-s <dd>Limit time values stored in output files to values that are the same whether they're taken to be signed or unsigned. You can use this option to generate SVVS-compatible files. <dt>-y command <dd>Use the given command rather than yearistype when checking year types (see below). </dl> Input lines are made up of fields. Fields are separated from one another by any number of white space characters. Leading and trailing white space on input lines is ignored. An unquoted sharp character (#) in the input introduces a comment which extends to the end of the line the sharp character appears on. White space characters and sharp characters may be enclosed in double quotes (") if they're to be used as part of a field. Any line that is blank (after comment stripping) is ignored. Non-blank lines are expected to be of one of three types: rule lines, zone lines, and link lines. A rule line has the form: <table border=1> <tr><td>Rule<td>NAME<td>FROM<td>TO<td>TYPE<td>IN<td>ON<td>AT<td>SAVE<td>LETT ER/S <tr><td colspan=10>For example: <tr><td>Rule<td>US<td>1967<td>1973<td>-<td>Apr<td>lastSun<td>2:00<td>1:00<td >D </table> The fields that make up a rule line are: <dl> <dt>NAME <dd>Gives the (arbitrary) name of the set of rules this rule is part of. <dt>FROM <dd>Gives the first year in which the rule applies. Any integer year can be supplied; the Gregorian calendar is assumed. The word minimum (or an abbreviation) means the minimum year representable as an integer. The word maximum (or an abbreviation) means the maximum year representable as an integer. Rules can describe times that are not representable as time values, with the unrepresentable times ignored; this allows rules to be portable among hosts with differing time value types. <dt>TO <dd>Gives the final year in which the rule applies. In addition to minimum and maximum (as above), the word only (or an abbreviation) may be used to repeat the value of the FROM field. <dt>TYPE <dd>Gives the type of year in which the rule applies. If TYPE is - then the rule applies in all years between FROM and TO inclusive. If TYPE is something else, then zic executes the command: yearistype year type To check the type of a year: An exit status of zero is taken to mean that the year is of the given type; An exit status of one is taken to mean that the year is not of the given type. <dt>IN <dd>Names the month in which the rule takes effect. Month names may be abbreviated. <dt>ON <dd>Gives the day on which the rule takes effect. Recognized forms include: <table border=1> <tr><td>5<td>the fifth of the month <tr><td>lastSun<td>the last Sunday in the month <tr><td>lastMon<td>the last Monday in the month <tr><td>Sun>=8<td>first Sunday on or after the eighth <tr><td>Sun<=25<td>last Sunday on or before the 25th </table> Names of days of the week may be abbreviated or spelled out in full. Note that there must be no spaces within the ON field. <dt>AT <dd>Gives the time of day at which the rule takes effect. Recognized forms include: <table border=1> <tr><td>2<td>time in hours <tr><td>2:00<td>time in hours and minutes <tr><td>15:00<td>24-hour format time (for times after noon) <tr><td>1:28:14<td>time in hours, minutes, and seconds <tr><td>-<td>equivalent to 0 </table> 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. <dt>SAVE <dd>Gives the amount of time to be added to local standard time when the rule is in effect. This field has the same format as the AT field (although, of course, the w and s suffixes are not used). <dt>LETTER/S <dd>Gives the "variable part" (for example, the "S" or "D" in "EST" or "EDT") of time zone abbreviations to be used when this rule is in effect. If this field is -, the variable part is null. </dl> A zone line has the form: <table border=1> <tr><td>Zone<td>NAME<td>GMTOFF<td>RULES/SAVE<td>FORMAT<td>[UNTIL] <tr><td colspan=6>For example: <tr><td>Zone<td>Australia/Adelaide<td>9:30<td>Aus<td>CST<td>1971 Oct 31 2:00 </table> The fields that make up a zone line are: <dl> <dt>NAME <dd>The name of the time zone. This is the name used in creating the time conversion information file for the zone. <dt>GMTOFF <dd>The amount of time to add to UTC to get standard time in this zone. This field has the same format as the AT and SAVE fields of rule lines; begin the field with a minus sign if time must be subtracted from UTC. <dt>RULES/SAVE <dd>The name of the rule(s) that apply in the time zone or, alternately, an amount of time to add to local standard time. If this field is - then standard time always applies in the time zone. <dt>FORMAT <dd>The format for time zone abbreviations in this time zone. The pair of characters %s is used to show where the "variable part" of the time zone abbreviation goes. Alternately, a slash (/) separates standard and daylight abbreviations. <dt>UNTIL <dd>The time at which the UTC offset or the rule(s) change for a location. It is specified as a year, a month, a day, and a time of day. If this is specified, the time zone information is generated from the given UTC offset and rule change until the time specified. The month, day, and time of day have the same format as the IN, ON, and AT columns of a rule; trailing columns can be omitted, and default to the earliest possible value for the missing columns. The next line must be a 'continuation' line; this has the same form as a zone line except that the string "Zone" and the name are omitted, as the continuation line will place information starting at the time specified as the UNTIL field in the previous line in the file used by the previous line. Continuation lines may contain an UNTIL field, just as zone lines do, indicating that the next line is a further continuation. </dl> A link line has the form: <table border=1> <tr><td>Link<td>LINK-FROM<td>LINK-TO <tr><td colspan=3>For example: <tr><td>Link<td>Europe/Istanbul<td>Asia/Istanbul </table> The LINK-FROM field should appear as the NAME field in some zone line; the LINK-TO field is used as an alternate name for that zone. Except for continuation lines, lines may appear in any order in the input. Lines in the file that describes leap seconds have the following form: <table border=1> <tr><td>Leap<td>YEAR<td>MONTH<td>DAY<td>HH:MM:SS<td>CORR<td>R/S <tr><td colspan=7>For example: <tr><td>Leap<td>1974<td>Dec<td>31<td>23:59:60<td>+<td>S </table> The YEAR, MONTH, DAY, and HH:MM:SS fields tell when the leap second happened. The CORR field should be "+" if a second was added or "-" if a second was skipped. <table> <tr><td>  <td> There's no need to document the following, since it's impossible for more than one leap second to be inserted or deleted at a time. The C Standard is in error in suggesting the possibility. See Terry J Quinn, The BIPM and the accurate measure of time, Proc IEEE 79, 7 (July 1991), 894-905. <dl><dt><dd>or "++" if two seconds were added or "--" if two seconds were skipped.</dl></table> The R/S field should be (an abbreviation of) "Stationary" if the leap second time given by the other fields should be interpreted as UTC or (an abbreviation of) "Rolling" if the leap second time given by the other fields should be interpreted as local wall clock time. <h3>NOTE</h3> For areas with more than two types of local time, you may need to use local standard time in the AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. <h3>FILE</h3> /usr/local/etc/zoneinfo standard directory used for created files <h3>SEE ALSO</h3> newctime(3), tzfile(5), zdump(8) <pre>@(#)zic.8 7.19</pre> This is the HTML version of the file "zic.8" in the tzcode folder. </body> </html>

2 1

FW: Time Zone Issues
by Olson, Arthur David (NCI) April 19, 2000

April 19, 2000

Andre-Tascha is on the time zone mailing list. --ado > -----Original Message----- > From: Andre-Tascha Lamme [SMTP:andre-tascha.lamme@ironriver.com] > Sent: Thursday, April 13, 2000 10:18 PM > To: Olson, Arthur David (NCI) > Subject: Time Zone Issues > > Arthur, > > Figured I would add you to the list of folks I have contacted over the > last couple of days. > > I am putting together some controls for windows developers overseas to > enable them to utilize all aspects of time zones (including the > ever-present > and pain in the rear DST variance). The data you have put together is the > closest thus far to what I am looking for. > > I cannot believe that somebody on the web hasn't posted a > straightforward > database with all the basic info for all applicable regions (well as much > as > can be done with such at least). I have gone through the data2000d.tar.gz > file you posted on the ftp site and has much of the data I am looking for, > but can be a bit confusing. Am I just an idiot? <grin> > > Do you know of this straightforward and exhaustive source (obviously do > not want to do 1000+ clicks to get the data from somebody's java app)... > > many thanks, > > andre'-tascha

4 3