- tz - lists.iana.org

Time zone converter, FAQ (kind of)
by Dee Ann Abel May 28, 1998

May 28, 1998

Time zone gurus, I am working on adding some notes to the Burbs Time Zone Converter (http://www.burbs.com/cgi-bin/tzconvert.pl) that will, I hope, reduce the number of questions I get. I have the following so far. Please let me know if I there are mistakes or if you have suggestions on something I should add: "The database that this converter is based on has been in widespread use for more than ten years. It is well maintained. Current common conversions (such as North American, European, Australian, and Japanese conversions) are most likely correct.", "'EST', 'CST', 'MST', and 'PST' do not take into consideration daylight savings time. These are US designations.", "Keep in mind that Australia's summer, and therefore their daylight savings time, is opposite the northern hemisphere.", "Saskatchewan (Canada) does not observe daylight savings time, and is six hours behind GMT throughout the year.", "Part of Indiana (US), including Indianapolis, does not observe daylight savings time, and is five hours behind GMT throughout the year.", "MST stands for US Mountain Standard Time, not Mid-Europe Summer Time. Use CET for the time in Central Europe.", "EST stands for US Eastern Standard Time. This is not an Australian time zone.", Thank you! Dee Ann Abel --------------------------------------------- Backgammon Ladder http://www.burbs.com/backgammon/ Please include your ladder name and, where relevent, your opponents name, preferably in the subject, in e-mail messages to backgammon(a)burbs.com Thanks! Check http://www.burbs.com/cgi-bin/tzconvert.pl for help with time zones.

1 0

Time zone converter bug report
by Dee Ann Abel May 26, 1998

May 26, 1998

Time zone gurus, I use the time zone database developed by this group in my time zone converter (http://www.burbs.com/cgi-bin/tzconvert.pl) I refer to it in the help files for the converter as the "NIH database" but that isn't really right. How should I refer to this database? I had a few bugs in the interface (I've addressed most of them), and decided to put a "bug reporter" up. Through this I expect that from time to time I will receive reports like this one, below. I thought I'd forward them on to this list so that they could either be explained or addressed. Thanks, Dee Ann Abel Note: The converter reports that their is currently two hours difference >Subject: Time zone converter bug report > >userAgent = Mozilla/2.0 (compatible; MSIE 3.02; Windows 95) >appName = Microsoft Internet Explorer >appVersion = 2.0 (compatible; MSIE 3.02; Windows 95) >email = marylouf(a)cba.org >errorType = other >comments = Saskatchewan only observes daylight savings time in the winter. (Currently, there is only a 1 hour time difference between EST and Sask. time) > >Input_year => 1998 >Input_BugReportForm.x => 10 >Input_BugReportForm.y => 11 >Input_oclock => PM >Input_day => 25 >Input_tzone1 => Canada/ >Input_tzone2 => East-Saskatchewan >Input_language => en >Input_month => 5 >Input_zone1 => Canada/ >Input_zone2 => Eastern >Input_thetime => 1:00 >

2 2

RE: tz interface problems
by Olson, Arthur David May 25, 1998

May 25, 1998

I've removed D. J. Bernstein from the time zone mailing list. --ado

1 0

Re a little help
by Sue Ann Bowling May 25, 1998

May 25, 1998

So far as time zones for remote stations providing met data, there should be something about the current time zone, at least, at the world meteorological organization, since observations are reduced to UT. Sue Ann Bowling, Geophysical Institute, University of Alaska Fairbanks Professional URL <http://climate.gi.alaska.edu/Bowling/Bowling.html> Dog URL<http://bowlingsite.mcf.com/DogPage.html>

1 0

a little help? (ok, maybe more than just a litte)
by CHancuff May 25, 1998

May 25, 1998

I know this is rather bold for my first post to this list. I need some assistance in the current time zone and DST information on the following places. UTC variation and begining and ending dates of DST (if observed) would be great. ASHMORE AND CARTIER ISLANDS BAKER ISLAND BASSAS DA INDIA BOUVET ISLAND BRITISH INDIAN OCEAN TERRITORY CLIPPERTON ISLAND CORAL SEA ISLANDS EUROPA ISLAND FRENCH SOUTHERN AND ANARCTIC LANDS GAZA STRIP GUERNSEY HEARD ISLAND AND MACDONALD ISLANDS HOWLAND ISLAND ISLE OF MAN JARVIS ISLAND JERSEY JUAN DE NOVA ISLAND MONTENEGRO NAVASSA ISLAND PALMYRA ATOLL PARACEL ISLANDS PITCAIRN ISLANDS SOUTH GEORGIA AND THE SOUTH SANDWICH SPRATLY ISLANDS TOKELAU TROMELIN ISLAND VATICAN CITY WESTERN SAHARA TIA (timidly said) Cliff Hancuff

2 1

error in zone.tab
by Alex LIVINGSTON May 25, 1998

May 25, 1998

I believe I've spotted an error in the zone.tab file: NZ -4355+17630 Pacific/Chatham Chatham Island Isn't Chatham Island east of the 180 degree meridian (though west of the "International Date Line")? _______________ Alex LIVINGSTON Macintosh Support IT, Australian Graduate School of Management (AGSM), Uni. of NSW (UNSW) Fax: +61 2 9931-9349 / Phone: +61 2 9931-9264 / Time: UTC + 10 or 11 h.

2 1

Re: tz leap second bug encountered by sendmail 8.8.8 in Australia
by Bradley White May 25, 1998

May 25, 1998

> The basic problem is that tz code looks at the system file > .../zoneinfo/GMT to decide what leap seconds to use when computing > GMT; this leads to bogus results if the user wants leap seconds and > the system file doesn't (or vice versa). Might I proffer that this is not a problem with the tz code, but a truthful representation of the situation presented to it. If "the user wants leap seconds and the system file doesn't (or vice versa)," the user is just kidding themselves. Either the system clock ticks leap seconds (a stationary epoch), or it doesn't. All tz files used on the system should reflect that reality. The suggested gmtoff() algorithm will always produce such varying results if localtime() and gmtime() cannot agree on minute boundaries, whether the discrepancy is a leapsecond artifact or not. Bradley

3 4

Re: proposed tz changes for Davis Station, Palestine, etc.
by Paul Eggert May 24, 1998

May 24, 1998

In my most recent proposed change I forgot to update zone.tab for Davis. Also, some URLs in tzselect.ksh are obsolescent. Here's a further patch. =================================================================== RCS file: RCS/tzselect.ksh,v retrieving revision 1997.9 retrieving revision 1997.9.1.1 diff -u -r1997.9 -r1997.9.1.1 --- tzselect.ksh 1997/12/29 14:53:41 1997.9 +++ tzselect.ksh 1998/05/24 19:15:13 1997.9.1.1 @@ -10,7 +10,7 @@ # If your host lacks the Korn shell, # you can use either of the following free programs instead: # -# <a href=ftp://ftp.gnu.ai.mit.edu/pub/gnu/> +# <a href=ftp://ftp.gnu.org/pub/gnu/> # Bourne-Again shell (bash) # </a> # @@ -22,7 +22,7 @@ # If your host lacks awk, or has an old awk that does not conform to Posix.2, # you can use either of the following free programs instead: # -# <a href=ftp://ftp.gnu.ai.mit.edu/pub/gnu/> +# <a href=ftp://ftp.gnu.org/pub/gnu/> # GNU awk (gawk) # </a> # =================================================================== RCS file: RCS/zone.tab,v retrieving revision 1.2.1.6 retrieving revision 1.2.1.7 diff -u -r1.2.1.6 -r1.2.1.7 --- zone.tab 1998/05/24 07:36:46 1.2.1.6 +++ zone.tab 1998/05/24 19:15:37 1.2.1.7 @@ -33,6 +33,7 @@ AQ -9000+00000 Antarctica/South_Pole Amundsen-Scott Station, South Pole AQ -6448-06406 Antarctica/Palmer Palmer Station, Anvers Island AQ -6736+06253 Antarctica/Mawson Mawson Station, Holme Bay +AQ -6835+07758 Antarctica/Davis Davis Station, Vestfold Hills AQ -6617+11031 Antarctica/Casey Casey Station, Bailey Peninsula AQ -6640+14001 Antarctica/DumontDUrville Dumont-d'Urville Base, Terre Adelie AR -3436-05827 America/Buenos_Aires E Argentina (BA, DF, SC, TF)

1 0

FW: tz interface problems
by Olson, Arthur David May 23, 1998

May 23, 1998

---------- From: D. J. Bernstein[SMTP:djb@cr.yp.to] Sent: Monday, May 18, 1998 3:32 AM To: arthur_david_olson(a)nih.gov; djb(a)cr.yp.to Subject: tz interface problems 1. Check out the dates produced by sendmail on one host: Mon, 18 May 1998 16:36:37 +0930 Mon, 18 May 1998 16:36:38 +0930 Mon, 18 May 1998 16:36:39 +0929 Mon, 18 May 1998 16:36:40 +0929 The problem, of course, is that sendmail is figuring out the offset by comparing the hours and minutes shown by localtime() and gmtime(). Mailers don't care about time zone names; they want the UTC offset. Do you have a routine that, given a time, returns the offset? (1-second offsets can't be expressed in mail, but that's a separate problem.) 2. I'm sure you're aware that BSD and Linux now include your routines. Unfortunately, they don't make it easy for typical users to regenerate the time-zone files. Users could download new files, but that's a megabyte of data. The practical effect is that many systems slipped by a second in 1997, and will probably slip by another second at the end of 1998. How difficult would it be for you to get leap-second data from another file? I've been working on the Y2038 problem, and I've put together an /etc/leapsecs.dat format for recording leap seconds. ---Dan

4 5

Re: FW: tz interface problems
by Bradley White May 22, 1998

May 22, 1998

> The problem, of course, is that sendmail is figuring out the offset by > comparing the hours and minutes shown by localtime() and gmtime(). > > That method should be reliable, so long as you pass the same timestamp > to both localtime and gmtime. Can you give more details about the problem? > > Do you have a routine that, given a time, returns the offset? > > There's not one in the tz packages, but one is commonly included in GNU code. > I'll enclose a copy at the end of this message. Of course the Right Way > to do it is to use tm_gmtoff, but this isn't blessed by the standards. > /* Yield A - B, measured in seconds. */ > time_t > difftm (a, b) > struct tm const *a; > struct tm const *b; > { : > } > > /* Yield the number of seconds that local time is ahead of GMT at > time T, or 0 if this is not known. */ > long > gmtoff (t) > time_t t; > { : > return difftm (ltp, &gmt); > } If you only need gmtoff() [and not the full generality of difftm()], a more simple solution that utilizes the fact that localtime() and gmtime() are never more than one day apart is ... long gmtoff(time_t t) { struct tm lcl = *localtime(&t); struct tm utc = *gmtime(&t); if (lcl.tm_mday != utc.tm_mday) (((lcl.tm_mon == utc.tm_mon) == (lcl.tm_mday > utc.tm_mday)) ? &lcl : &utc)->tm_hour += 24; return ((lcl.tm_hour - utc.tm_hour) * 60) + (lcl.tm_min - utc.tm_min); } Bradley

1 0