- tz - lists.iana.org

Timezone with new Brazil rules
by Ricardo Reis Sept. 8, 1999

Sept. 8, 1999

Hi, I would like to know when will you have a timezone version that includes the new Brazil's rules (daylight savings from oct 3 untill feb 26)? I am attaching a southamerica file that I have edited to add those changes, but I would prefer to use a more "official" version since I am not sure if my file will work fine. I am looking forward to hearing from you. Regards, Ricardo. -- Ricardo R. B. Reis Sao Paulo IT Morgan Stanley do Brasil

1 0

FW: Installation of tzcode1999e_tar.gz and tzdata1999e_tar.gz
by Olson, Arthur David (NCI) Sept. 7, 1999

Sept. 7, 1999

Note that Luis is not on the time zone mailing list; be sure to direct relevant replies to Luis. --ado -----Original Message----- From: Luis Miguel Navas Santos [SMTP:lnavas@MyAlert.com] Sent: Friday, September 03, 1999 6:25 AM To: tz(a)elsie.nci.nih.gov Subject: Installation of tzcode1999e_tar.gz and tzdata1999e_tar.gz Hello. I would like to ask you a question about the installation of these packages in HP-UX 11.0. I have installed them and I have two warnings: cc: "localtime.c", line 1260: warning 527: Integral value implicitly converted to pointer in assignment. /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (date.o) was detected. The linked output may not run on a PA 1.x system. But up to here, everything is OK (every executable is in the right place, under the /usr/local/ directory, and the PATH variable is set correctly). I set the TZ variable to, for example, America/New_York and the date command doesn't give me the right time. I have checked the file /usr/bin/locale and it's a PA-RISC1.1 shared executable dynamically linked. Maybe that's the problem. Could you tell me how can I update the version of this file, or how can I compile the package to be able to execute the included files for the PA 1.1?. Nevertheless, the directory /usr/lib/locale and its subdirectories don't exist. This could be another posible mistake. I have checked a Solaris installation and it exists and works. There is an option in the Makefile which allows to set the path to the "locale". I don't know what this exactly means. Is it a reference to the executable file or a reference to the Sun-like subdirectory. If you could tell me some suggestions or posible solutions I would really appreciate it. Thank you in advance, Luis Miguel Navas.

2 1

[Fwd: time in Nunavut]
by Antoine Leca Sept. 6, 1999

Sept. 6, 1999

Rives McDow <rmcdow(a)enteles.com> wrote the attached message in the IETF-calendar mailing list, about a new change of timezones in Nunavut. I tried to find more informations about the current timezones in this area, and it appears that there is a problem about current datas, concerning America/Pangnirtung: <http://www.arctictravel.com/chapters/pangpage.html> says they operate under Eastern Time (our datas give Atlantic time). Outside this problem, I have tried to draft the change as the news says. Contrary to what Rives thought, it appears that the new timezone will be Central Time, not Eastern Time (that is, Iqaluit which is in the Baffin Region will change from EDT to CST, setting their clocks back two hours). As we know, these kinds of change yield problem, because some moments in the gap are not clearly defined as either EDT or CST... I then drafted two lines for representing it. I also created a new timezone for the Kitikmeot region, to differentiate it from the Yellowknife region which is still in (the remaining of) Northern Territories, and thus still operate Mountain Time. I named it America/Cambridge_Bay, after the most populated "city" (1,351 inhabitants according to <http://www.arctictravel.com/chapters/cambridgepage.html>). Please review the attached changes to confirm it is OK. At least, the year of change for America/Pangnirtung should be established (perhaps by placing America/Pangnirtung in Eastern Time since 1884). Antoine --- northamerica.99e Tue Aug 17 20:09:08 1999 +++ northamerica Mon Sep 6 15:21:14 1999 @@ -888,6 +888,29 @@ # * O.I.C. 1980/02 established DST. # * O.I.C. 1987/056 changed DST to Apr firstSun 2:00 to Oct lastSun 2:00. # Shanks says Yukon's 1973-10-28 switch was at 2:00; go with Englander. +# +# From Antoine Leca (1999-09-06): +# According to <http://www.arctictravel.com/chapters/travelinfopage.html>, +# Nunavut only uses three timezones, namely Mountain Time for Kitikmeot, +# Central Time for Kivalliq alias Keematin, and Eastern Time for (most of) +# the Baffin Region. This means that at an unknown date, Pangnirtung +# moves from Atlantic Time to Eastern Time. This is confirmed by +# <http://www.arctictravel.com/chapters/pangpage.html>. +# +# From Rives McDow <rmcdow(a)enteles.com> (1999-09-04): +# The new territory of Nunavut [created 1999-04-01], in what was formerly +# part of the Northwest Territory in Canada, moved very quickly to +# incorporate the whole territory into one time zone. The change +# announcement can be viewed at +# <http://www.nunatsiaq.com/nunavut/nvt90903_13.html>. +# +# From Antoine Leca (1999-09-06): +# We then need to create a new timezone for the Kitikmeot region of Nunavut +# to differentiate it from the Yellowknife region. +# The hours of the changes are tentatives... +# Since the eastern part set their clocks back two hours, we anyway +# have to split the change in two parts. + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NT_YK 1918 only - Apr 14 2:00 1:00 D @@ -903,16 +926,25 @@ Rule NT_YK 1987 max - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Pangnirtung -4:22:56 - LMT 1884 - -4:00 NT_YK A%sT + -4:00 NT_YK A%sT 19XX + -5:00 NT_YK E%sT 1999 Oct 31 3:00 + -6:00 - CST 1999 Oct 31 2:00 + -5:00 NT_YK C%sT Zone America/Iqaluit -4:33:52 - LMT 1884 # Frobisher Bay - -5:00 NT_YK E%sT -Zone America/Rankin_Inlet -6:08:40 - LMT 1884 + -5:00 NT_YK E%sT 1999 Oct 31 3:00 + -6:00 - CST 1999 Oct 31 2:00 + -6:00 NT_YK C%sT +Zone America/Rankin_Inlet -6:08:40 - LMT 1884 # Kivalliq, Keewatin + -6:00 NT_YK C%sT +Zone America/Cambridge_Bay -7:37:24 - LMT 1884 # Kitikmeot + -7:00 NT_YK M%sT 1999 Oct 31 02:00 -6:00 NT_YK C%sT Zone America/Yellowknife -7:37:24 - LMT 1884 -7:00 NT_YK M%sT Zone America/Inuvik -8:54:00 - LMT 1884 -8:00 NT_YK P%sT 1979 Apr lastSun 2:00 - -7:00 NT_YK M%sT + -7:00 NT_YK M%sT 1999 Oct 31 1:00 + -5:00 NT_YK E%sT Zone America/Whitehorse -9:00:12 - LMT 1900 Aug 20 -9:00 NT_YK Y%sT 1966 Jul 1 2:00 -8:00 NT_YK P%sT

1 1

Installation of tzcode1999e_tar.gz and tzdata1999e_tar.gz
by Luis Miguel Navas Santos Sept. 3, 1999

Sept. 3, 1999

Hello. I would like to ask you a question about the installation of these packages in HP-UX 11.0. I have installed them and I have two warnings: cc: "localtime.c", line 1260: warning 527: Integral value implicitly converted to pointer in assignment. /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (date.o) was detected. The linked output may not run on a PA 1.x system. But up to here, everything is OK (every executable is in the right place, under the /usr/local/ directory, and the PATH variable is set correctly). I set the TZ variable to, for example, America/New_York and the date command doesn't give me the right time. I have checked the file /usr/bin/locale and it's a PA-RISC1.1 shared executable dynamically linked. Maybe that's the problem. Could you tell me how can I update the version of this file, or how can I compile the package to be able to execute the included files for the PA 1.1?. Nevertheless, the directory /usr/lib/locale and its subdirectories don't exist. This could be another posible mistake. I have checked a Solaris installation and it exists and works. There is an option in the Makefile which allows to set the path to the "locale". I don't know what this exactly means. Is it a reference to the executable file or a reference to the Sun-like subdirectory. If you could tell me some suggestions or posible solutions I would really appreciate it. Thank you in advance, Luis Miguel Navas.

1 0

Newbie questions... regarding tzdata199e.tar.gz
by Jon R. Kibler Sept. 2, 1999

Sept. 2, 1999

(If this is now where I should be asking these questions, I apologize -- please direct me to the correct source.) I am new at time zone information, so please bear with me. I have to develop a "Y2K Rollover Model." Looking for time zone information, I found the tzdata199e.tar.gz archive (at ftp://elsie.nci.nih.gov/pub/) -- which is great -- exactly what I needed. I believe that I understand most of it, but I have a few questions. Most of them are about the fine points of how the rules work: 1) From 'africa', Sierra Leone has the following entry: > # Sierra Leone > # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > # Whitman gives Mar 31 - Aug 31 for 1931 on; go with Shanks. > Rule SL 1935 1942 - Jun 1 0:00 0:40 SLST > Rule SL 1935 1942 - Oct 1 0:00 0 WAT > Rule SL 1957 1962 - Jun 1 0:00 1:00 SLST > Rule SL 1957 1962 - Sep 1 0:00 0 GMT > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Africa/Freetown -0:53:00 - LMT 1882 > -0:53:00 - FMT 1913 Jun # Freetown Mean Time > -1:00 SL %s 1957 > 0:00 SL %s 1a) It is my interpretation that no rules apply after Sep 1, 1962 -- is this a correct interpretation? If not, please explain. 1b) If no rules apply, then what letters are used for SL time? (As I interpret it, %s would be blank if no rules apply. If this is not the case, please explain.) 1c) If no rules apply, why not specify a "no rules" entry, such as the following? (I would think it would be much easier [less ambiguous] for HUMANS to read, and thus less likely to contain mistakes.) > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Africa/Freetown -0:53:00 - LMT 1882 > -0:53:00 - FMT 1913 Jun # Freetown Mean Time > -1:00 SL %s 1957 > 0:00 SL %s 1962 Sep 1 > 0:00 - GMT 2) Please explain a "Numeric RULE", such as in the following example for Cape Verde: > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Atlantic/Cape_Verde -1:34:04 - LMT 1907 # Praia > -2:00 - CVT 1942 Sep > -2:00 1:00 CVST 1945 Oct 15 # <<< Please explain > -2:00 - CVT 1975 Nov 25 2:00 > -1:00 - CVT 3) Please explain "TYPE", such as in the following rule for South Australia: > # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule AS 1990 1994 even Mar Sun>=18 2:00s 0 - > Rule AS 1990 1994 odd Mar Sun>=1 2:00s 0 - 4) For the rules shown in "4" above, what does the "s" on the "AT time" mean? I have also seen other letters, such as "u" -- what letters are used and what is their meaning? 5) Where is the format for the Zone, Rules, Links, etc. defined and the syntax for each entry documented? (If I could have found that info, I probably would not have had to bother you with all these dumb questions!) I GREATLY thank you for your time in answering all these newbie questions! Sincerely, Jon R. Kibler Systems Architect Year 2000 Services Manager Jon.Kibler(a)aset.com Advanced Systems Engineering Technology 389 Johnnie Dodds Blvd., Suite 205 Mt. Pleasant, SC 29464-2950 (Charleston) Phone: (843) 849-8214 Fax: (843) 849-8215

1 0

FW: DST changes in australasia due to 2000 Olympics
by Olson, Arthur David (NCI) Sept. 2, 1999

Sept. 2, 1999

Please include Carol (who is not on the time zone mailing list) in any replies. --ado -----Original Message----- From: cfields(a)kapaa.eng.sun.com [SMTP:cfields@kapaa.eng.sun.com] Sent: Wednesday, August 11, 1999 2:55 PM To: tz(a)elsie.nci.nih.gov Subject: DST changes in australasia due to 2000 Olympics I am fixing a zoneinfo bug in Solaris. One of our customers has pointed out that daylight saving should be fixed for NSW due to the Sydney Olympics. The NSW government web site, http://dir.gis.nsw.gov.au/cgi-bin/genobject/document/other/daylightsaving/t… ITWr0 shows the following: -------- Daylight saving will commence on the last Sunday in October at 2:00am EST and continue until the last Sunday in March at 3:00am EDST. 1998 - 1999 Start: Sunday October 25, 1998 Finish: Sunday March 28, 1999 1999 - 2000 Start: Sunday October 31, 1999 Finish: Sunday March 26, 2000 2000 - 2001 Start: Sunday August 27, 2000 Finish: Sunday March 25, 2001 (Starting at 2.00am and Finishing at 2.00am) -------- In tzdata1999d (australasia 7.46), Rule AV and AN show the daylight saving change on Aug 26 in 2000. Would the following fix the correct set of timezones that are adopting this change? % diff australasia australasia.fix 116c116 < Rule AV 2000 only - Aug 26 2:00s 1:00 - --- > Rule AV 2000 only - Aug lastSun 2:00s 1:00 - 136c136 < Rule AN 2000 only - Aug 26 2:00s 1:00 - --- > Rule AN 2000 only - Aug lastSun 2:00s 1:00 - Carol Fields carol.fields(a)eng.sun.com

3 2

Summer Time, Channel Islands, 1916
by Joseph S. Myers Sept. 2, 1999

Sept. 2, 1999

I today found the 1916 summer time orders for the Channel Islands in the Public Record Office (HO 45/10811/312364). This resolves one residual dubious claim of Shanks in the europe file: Alderney, Jersey and Guernsey all enacted summer time for 1916 (and the enactment for the Isle of Man is already noted). This doesn't complete the resolution of timekeeping in the Channel Islands, since 1917-1921 need to be resolved for the Channel Islands, and it isn't clear whether the islands were using GMT or local time then. The changes in Alderney and Guernsey were at the same 2am GMT time as for Great Britain; the order for Jersey is more interesting. Other things in this file include a poster advertising the change in Ireland from Dublin-based time to Greenwich mean time, and one advertising the introduction of summer time in the UK in 1916 (100000 copies printed); and the information that (a) it was originally proposed to implement summer time by Order in Council under the Defence of the Realm Acts, but it was decided that although this would be legal it would make things clearer to do it by Act of Parliament; and (b) a Bill to change Ireland to using the same time as England had passed in the Lords in 1912 but was not proceeded with in the Commons. This file, and another (HO 45/11077/411632 - on international coordination of summer time) include various laws and regulations of other European countries on summer time around that time, though the proper histories of summer time in these countries are no doubt more readily created by someone living there. It seems that there was a conference at the Home Office on 22 November 1921 with representative of France and Belgium to discuss reaching common summer time dates with them. Alderney ======== [This one is in manuscript.] A la Cour de l'Ile d'Auregny Le 17 Mai 1916, par devant John Main Duplain, écuyer, Lieut-juge; présents :- John Pierre Gallichan, Nicolas William Gaudion, et Thomas John Robilliard, écuyers, Jurés. ``Ordonnance Provisoire Portant Modification à l'Heure Légale''. La Cour, ouies les conclusions du Procureur du Roi, a ordonné et ordonne :- Dans la présente année, 1916, l'heure légale en cette île sera avancée d'une heure, depuis deux heures du matin (temps moyen de Greenwich) de Dimanche le 21 Mai, jusqu'à deux heures du matin (temps moyen de Greenwich) de Dimanche le 1^er Octobre. Pendant la période susdite, l'heure mentionnée ou à laquelle allusion est faite dans les Proclamations, les Actes de Parlement, les Ordres en Conseil, les Ordonnances de la Cour, en vigueur dans cette île, dans des contrats, des règlements, des statuts, des avertissements, des affiches, ou dans tout autre document ou toute affaire quelconque, sera censée être l'heure préscrite dnas la présente Ordonnance. Et ne déroge en rien cette Ordonnance à l'usage de l'heure, temps moyen de Greenwich, pour les besoins de l'astronomie ou de la navigation ni à l'interprétation d'aucun document qui mentionne ou qui a référence à l'heure ayant rapport à l'astronomie et à la navigation. Et sera la présente Ordonnance publieé et affichée aux lieux ordinaries afin que personne n'en prétende cause d'ignorance. (Extrait des Registres) Charles R Leboeq Greffier du Roi Jersey ====== HEURE OFFICIELLE. ----- Acte avançant l'heure officielle pendant les mois d'été. ----- Aux Etats de l'Ile de Jersey. ----- L'An 1916, le 13e jour de Mai. ----- CONSIDÉRANT que le Parlement Britannique a, dans l'intérêt national, résolu d'avancer d'une heure la computation horaire dans le Royaume-Unia à partir de Dimanche le 21 Mai courant jusqu'à Dimanche le 1er Octobre prochain et ainsi de suite pareillement chaque année durant la présente guerre pendant telle période qui sera prescrite par Ordre de Sa Majesté en Conseil; Considérant que, lors de l'adoption, en 1898, de la Loi qui détermine actuellement l'heure officielle en cette Ile, les Etats ont déjà reconnu et affirmé le princpe que Jersey ne peut sans inconvénients rester en dehors de l'horaire qui prévaut dans las Grande Bretagne; Considérant que la différence entre l'heure locale alors en usage et celle de Greenwich n'était cependant que de quelques minutes tandis que maintenant l'écart de temps entre Jersey et la Grande Bretagne serait d'une heure entière pendant tout l'été, en sorte qu'un changement analogue s'impose ici; LES ETATS ont, d'urgence, adopté la disposition suivante: ARTICLE UNIQUE. Samedi le 20 courant à minuit l'heure officielle en cette Ile sera avancée d'une heure sur le temps moyen de Greenwich et ce jusqu'à Samedi le 30 Septembre prochain à minuit. Pareille avance sera opérée chaque année subséquente tant qu'il y aura nécessité de ce faire, et ce aux époques qui seront en temps et lieu déterminées par les Etats afin que l'heure officielle locale demeure en tout temps conforme à l'heure légale de la Grande Bretagne. Ce qui sera imprimé, publié et affiché. ERNEST LE SUEUR, Greffier. 50/1916 Guernsey ======== ORDONNANCE DE LA COUR ROYALE. ----------- ORDONNANCE PROVISOIRE Portant modification à L'HEURE LÉGALE (Passée aux Chefs-Plaids d'après Pâques remis au 13 mai 1916.) Guernesey: COMPAGNIE D'IMPRIMERIE DE BICHARD, LIMITÉE, BUREAU DE LA GAZETTE, RUE DU BORDAGE. ------ 1916. Ordonnance de la Cour Royale. A LA COUR ROYALE DE L'ILE DE GUERNESEY Aux Chefs-Plaids d'après Pâques remis au 13 mai 1916, pardevant Edward Chepmell Ozanne, écuyer, Bailiff; présents: Ernest Collas, George Edward Kinnersly, George Herbert Le Mottée, Julius Bishop, John Bonamy Collings, Adolphus John Hocart, Thomas William Mansell de Guérin, Lionel Slade Carey, James Esten de Jersey, Hubert George de Carteret Stevens Guille et William de Prélaz Crousaz, écuyers, Jurés. Ordonnance Provisoire portant Modification à l'Heure Légale. La Cour, ouïes les conclusions des Officiers du Roi, a ordonné et ordonne :- Dans la présente année, 1916, l'heure légale en cette île sera avancée d'une heure, depuis deux heures du matin (temps moyen de Greenwich) de Dimanche, le 21 mai, jusqu'à deux heures du matin (temps moyen de Greenwich) de Dimanche, le 1er octobre. Pendant la période susdite, l'heure mentionnée ou à laquelle allusion est faite dans les Proclamations, les Actes de Parlement, les Ordres en Conseil, les Ordonnances de la Cour Royale en vigueur dans cette île, dans des contrats, des règlements, des statuts, des avertissements, des affiches, ou dans tout autre document ou toute affaire quelconque, sera censée être l'heure préscrite dnas la présente Ordonnance. Et ne déroge en rien cette Ordonnance à l'usage de l'heure temps moyen de Greenwich pour les besoins de l'astronomie ou de la navigation ni à l'interprétation d'aucun document qui mentionne ou qui a référence à l'heure ayant rapport à l'astronomie et à la navigation. Et sera la présente Ordonnance publieé et affichée aux lieux ordinaries afin que personne n'en prétende cause d'ignorance. (Extrait des Registres), A. J. ROUSSEL, Député-Greffier du Roi. -- Joseph S. Myers jsm28(a)cam.ac.uk

1 0

C9X and Time
by Clive D.W. Feather Sept. 2, 1999

Sept. 2, 1999

Sorry it's taken me so long to get round to this. The last WG14 meeting agreed, in principle, that a work item could be started on new time facilities for C. The result of the work item would be a Normative Amendment that would add these facilities to the language. There was no objection to the proposal that the facilities be designed "from the ground up"; they do not have to be based on the existing <time.h> functions. Where do we want to go from here ? -- Clive D.W. Feather | Work: <clive(a)demon.net> | Tel: +44 20 8371 1138 Internet Expert | Home: <clive(a)davros.org> | Fax: +44 20 8371 1037 Demon Internet Ltd. | WWW: http://www.davros.org | Mobile: +44 973 377646

6 8

tzdata format
by D. J. Bernstein Aug. 31, 1999

Aug. 31, 1999

Supposedly rule lines can occur in any order. What do the following lines mean? Rule Silly 1999 only - Sep 3 5:00 2:00 X Rule Silly 1999 only - Sep 3 6:00 1:00 Y Rule Silly 1999 only - Sep 3 8:00 -3:00 Z Starting from 0:00 +0000, do we increase to 5:00 +0000, then jump to 7:00 +0200, then increase to 8:00 +0200, then jump to 3:00 -0300, then increase to 6:00 -0300, then jump to 10:00 +0100, then increase? Or do we increase to 6:00 +0000, then jump to 7:00 +0100, then increase to 8:00 +0100, then jump to 4:00 -0300, then increase to 5:00 -0300, then jump to 10:00 +0200, then increase? Why aren't transition times labelled with the starting offset? Or, more simply, always specified in terms of standard time? I see that Tunisia one year had two transitions in the same month. Why are these part of the rule rather than the zone? Are there other examples of two transitions in the same month? Are there any DST systems that don't consist of two jumps in each applicable year, one jump early in the year, one jump late in the year? Are there any rule lines that cover multiple years without being part of such a pair? ---Dan

3 3

Re: time.h design issues
by Ulrich Drepper Aug. 31, 1999

Aug. 31, 1999

Paul Eggert <eggert(a)twinsun.com> writes: > I agree that my proposed API is still too complicated. When I get the > time I'll try to simplify it. Your code is a valuable resource in > this area: implementation experience counts for a lot in my book. Well, then I hope you suggest an implementation for a monotonic time implementation. Constraints are: The underlying OS will not notify each running program about a sudden clock change and itself does not provide a monotonic clock. In this situation the only thing you can count on are some hardware "clocks" the kernel does not (or cannot) influence. I think about things like the time stamp counters found on many modern processors. But: - they are only found on modern processors, and therefore a generic implementation isn't possible - even if they are available, they might be useless if, as in the case of the Alpha, the counter range is too small (just do the math: a 32 bit counter increment in each clock cycle on machines with, as seen two weeks ago, 1GHz clock speed). What I meant to say is think about the implementation before you propose something. It is certainly nice to have such a timer but it is very often not possible to implement it and for exactly this reason we have adjtime(). -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

4 6

Tonga Daylight Savings Time
by Eric Ulevik Aug. 30, 1999

Aug. 30, 1999

On 19 August 1999, New Zealand TV's "ONE Network News" reported that Tonga will have DST from November to February, making it first into the new millenium. I don't have any details, unfortunately. Regards, Eric Ulevik eau(a)ozemail.com.au

1 0

FW: timezone improvements
by Olson, Arthur David (NCI) Aug. 30, 1999

Aug. 30, 1999

Robert E. Brown is not on the time zone mailing list; be sure to include Robert in any replies. --ado -----Original Message----- From: Robert E. Brown [SMTP:brownb@jany.gs.com] Sent: Thursday, August 26, 1999 1:24 PM To: tz(a)elsie.nci.nih.gov Subject: timezone improvements I work for a company that requires some capabilities beyond the standard time zone library. Here's the sort of thing we're interested in: Ability to efficiently do time calculations in several time zones at the same time in separate threads. Time zone functions might take a zone as argument instead of the current method of setting the TZ environment variable and calling tzset to change zones, which involves file I/O. Is there any prior art along these lines? I do see the routines whose names end with "_r". They seem to fix one glitch, but do not completely solve the problem. How can I get the capabilities I want integrated with the standard time zone library? By making it a part of the standard library, the chance increases that the code will be used, maintained, and completely debugged. We are willing to pay for the capabilities we want. Would Cygnus be a good source for this work? Do you have any other suggestions? Thanks very much. bob

6 16

Re: FW: timezone improvements
by Ulrich Drepper Aug. 27, 1999

Aug. 27, 1999

> How can I get the capabilities I want integrated with the standard time zone > library? By making it a part of the standard library, the chance increases > that the code will be used, maintained, and completely debugged. We are > willing to pay for the capabilities we want. Would Cygnus be a good source > for this work? Do you have any other suggestions? Thanks very much. I don't know exactly why you are referring to Cygnus. I guess because you associate my glibc work with my employer. And I also don't know which "standard library" you are referring to. glibc as used on Linux? You will most probably be out of luck trying to influence the commercial Unix vendors. If you know what interface you are looking for contact me and I can see whether it makes sense adding it to glibc. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

1 0

timezone improvements
by Robert E. Brown Aug. 26, 1999

Aug. 26, 1999

I work for a company that requires some capabilities beyond the standard time zone library. Here's the sort of thing we're interested in: Ability to efficiently do time calculations in several time zones at the same time in separate threads. Time zone functions might take a zone as argument instead of the current method of setting the TZ environment variable and calling tzset to change zones, which involves file I/O. Is there any prior art along these lines? I do see the routines whose names end with "_r". They seem to fix one glitch, but do not completely solve the problem. How can I get the capabilities I want integrated with the standard time zone library? By making it a part of the standard library, the chance increases that the code will be used, maintained, and completely debugged. We are willing to pay for the capabilities we want. Would Cygnus be a good source for this work? Do you have any other suggestions? Thanks very much. bob

1 0

Historical zone changes
by Lblumbbs＠aol.com Aug. 19, 1999

Aug. 19, 1999

In December 1941 I understand the time in Hawaii when it is on the hour in the Eastern Standard time zone was 30 minutes past the hour. Today ther minutes are the same. Can you tell me what the time zone difference between the Eastern Standard time zone and the time zone covering Hawaii was in 1941? Can you tell when (year and month) any changes to this time difference changed.

1 0

Re: tzcode1999e.tar.gz and tzdata1999e.tar.gz
by Ulrich Drepper Aug. 17, 1999

Aug. 17, 1999

Ado, > The files > ftp://elsie.nci.nih.gov/pub/tzcode1999e.tar.gz > and > ftp://elsie.nci.nih.gov/pub/tzdata1999e.tar.gz Unfortunately the files are not readable in the moment: -r-------- 1 8800 0 92586 Aug 17 19:28 tzcode1999e.tar.gz -r-------- 1 8800 0 104493 Aug 17 19:28 tzdata1999e.tar.gz -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

1 0

tzcode1999e.tar.gz and tzdata1999e.tar.gz
by Olson, Arthur David (NCI) Aug. 17, 1999

Aug. 17, 1999

The files ftp://elsie.nci.nih.gov/pub/tzcode1999e.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1999e.tar.gz are now available. These files incorporate the changes circulated last week by Paul Eggert on the time zone mailing list, although the change to handling of DST-specifying time zone names has been commented out for now (search for "XXX" in "localtime.c" for details). These files also do not make any changes to the start of DST in Brazil. In addition to Paul's changes, there are updates to "Arts.htm" and cleanups of URLs. I imagine we'll see 1999f shortly with both changes in "localtime.c" and "southamerica"; folks can judge whether to await 1999f before downloading. --ado

1 0

FW: Changes in Brazil's daylight savings
by Olson, Arthur David (NCI) Aug. 17, 1999

Aug. 17, 1999

Ricardo is not on the time zone list; be sure to include Ricardo in replies if appropriate. --ado -----Original Message----- From: Ricardo Reis [SMTP:rreis@ms.com] Sent: Tuesday, August 17, 1999 12:09 PM To: tz(a)elsie.nci.nih.gov Subject: Changes in Brazil's daylight savings Hi, just to inform that Brazil's daylight savings has been changed. Now it will start on Oct 03 1999 and will end on Feb 27 2000. I am attaching a southamerica file that includes this changes, but I am not experienced in this kind of updates, please rewrite it. Regards, Ricardo R. B. Reis <<southamerica.rreis>>

3 2

Changes in Brazil's daylight savings
by Ricardo Reis Aug. 17, 1999

Aug. 17, 1999

Hi, just to inform that Brazil's daylight savings has been changed. Now it will start on Oct 03 1999 and will end on Feb 27 2000. I am attaching a southamerica file that includes this changes, but I am not experienced in this kind of updates, please rewrite it. Regards, Ricardo R. B. Reis

1 0

RE: tz changes for Australia 2000 Olympics, Jordan, Poland, Brazi l, etc.
by Olson, Arthur David (NCI) Aug. 16, 1999

Aug. 16, 1999

... * Modify localtime.c to default to the current US rules if the TZ string specifies DST without rules, and if we can't load the default rules. ... + if (*name == '\0' && load_result != 0) + /* + ** Default to current US rules if TZ has no rules + ** and we can't load the default rules, + */ + name = ",M4.1.0,M10.5.0"; ... At the least we may want to refer to "US rules as of 1999-08-16" rather than "current US rules." We may also want to cite chapter and verse of an international standard (if applicable) to explain why U.S. rules are being used (to avoid bashing of U.S. computer imperialists). --ado

1 0

DST changes in australasia due to 2000 Olympics
by cfields＠kapaa.eng.sun.com Aug. 11, 1999

Aug. 11, 1999

I am fixing a zoneinfo bug in Solaris. One of our customers has pointed out that daylight saving should be fixed for NSW due to the Sydney Olympics. The NSW government web site, http://dir.gis.nsw.gov.au/cgi-bin/genobject/document/other/daylightsaving/t… shows the following: -------- Daylight saving will commence on the last Sunday in October at 2:00am EST and continue until the last Sunday in March at 3:00am EDST. 1998 - 1999 Start: Sunday October 25, 1998 Finish: Sunday March 28, 1999 1999 - 2000 Start: Sunday October 31, 1999 Finish: Sunday March 26, 2000 2000 - 2001 Start: Sunday August 27, 2000 Finish: Sunday March 25, 2001 (Starting at 2.00am and Finishing at 2.00am) -------- In tzdata1999d (australasia 7.46), Rule AV and AN show the daylight saving change on Aug 26 in 2000. Would the following fix the correct set of timezones that are adopting this change? % diff australasia australasia.fix 116c116 < Rule AV 2000 only - Aug 26 2:00s 1:00 - --- > Rule AV 2000 only - Aug lastSun 2:00s 1:00 - 136c136 < Rule AN 2000 only - Aug 26 2:00s 1:00 - --- > Rule AN 2000 only - Aug lastSun 2:00s 1:00 - Carol Fields carol.fields(a)eng.sun.com

1 0

FW: correction for tzdata/leapseconds
by Olson, Arthur David (NCI) July 22, 1999

July 22, 1999

Please include Michael Deckers in any replies; Michael is not part of the time zone mailing list. --ado -----Original Message----- From: Michael Deckers [SMTP:Michael.Deckers@mch6.siemens.de] Sent: Thursday, July 22, 1999 6:29 AM To: tz(a)elsie.nci.nih.gov Subject: correction for tzdata/leapseconds Just a quibble in the file "@(#)leapseconds 7.11" in ftp://elsie.nci.nih.gov/pub/tzdata1999d.tar.gz: # The International Earth Rotation Service periodically uses leap seconds # to keep UTC to within 0.9 s of TAI (atomic time); see ***************** This becomes correct only with UT1 in place of TAI. For instance: within 0.9 s of UT1 (Universal Time 1, the primary time scale measuring the rotation of the Earth) Since the rates of UTC and TAI are the same, the difference between TAI and UTC increases at each instant a leap second is inserted in UTC; currently it is 32 s. ------------------------------------------------------------------------ Michael H Deckers email: Michael.Deckers(a)mch6.siemens.de ---------------------------- end of mail -------------------------------

2 1

correction for tzdata/leapseconds
by Michael Deckers July 22, 1999

July 22, 1999

Just a quibble in the file "@(#)leapseconds 7.11" in ftp://elsie.nci.nih.gov/pub/tzdata1999d.tar.gz: # The International Earth Rotation Service periodically uses leap seconds # to keep UTC to within 0.9 s of TAI (atomic time); see ***************** This becomes correct only with UT1 in place of TAI. For instance: within 0.9 s of UT1 (Universal Time 1, the primary time scale measuring the rotation of the Earth) Since the rates of UTC and TAI are the same, the difference between TAI and UTC increases at each instant a leap second is inserted in UTC; currently it is 32 s. ------------------------------------------------------------------------ Michael H Deckers email: Michael.Deckers(a)mch6.siemens.de ---------------------------- end of mail -------------------------------

1 0

FW: timezone question
by Olson, Arthur David (NCI) July 19, 1999

July 19, 1999

Be sure direct replies to Durk, who's not on the time zone mailing list. --ado -----Original Message----- From: Durk Talsma [SMTP:d.talsma@direct.a2000.nl] Sent: Friday, July 16, 1999 11:09 AM To: tz(a)elsie.nci.nih.gov Subject: timezone question Hello, First of all, please let me introduce myself, my name is Durk Talsma, and I am currently helping in developing a GPL'ed Open Source Flightsimulator (http://www.flightgear.org) One of the things I'm currently working on is getting the local time right for any given location of an aircraft. Using your tzcode and tzdata packages, I started experimenting, and currently I am able to select the nearest timezone relative to an aircraft's position. I also found out that by faking a TZ environment variable, I'm capable of retrieving the right local time on my linux box. However, one of our goals is portability, and I don't know whether this trick will also work on other platforms, such as Windows or the Mac, using their native localtime() functions. So for this reason, I consider redistributing your timezone definition files with flightgear, along with a modified version of the glibc's localtime() function. For this reason, I have two questions. First, do you think it is necessary to do this, or is there a relatively simple way to get this information from the native OS'ses? And second, are we allowed to use your timezone information files, or code, and redistribute them with our project? By the way, the email adres I'm posting to right now was the only adress I could find for contacting you. Currently, I don't know who I'm sending this to, and I also don't know whether I'm sending this message to a private mail adress or a mailinglist. I also hope that my questions are appropriate to send to this adress. I've attached my latest message to the flightgear developers mailinglist below, to explain a little further what I'm working on. Thanks for reading. Best regards, Durk Talsma Hi, In part, this message is to give a small update on my timezone parsing code, and in part it is also intended to get some advice. First of all, it looks like I made good progress on the timezone parsing code. Currently, I'm able to parse the timezone database, and select the nearest timezone, based on the angle between my current location and the location of the timezone centerpoints, as described in the zone.tab file (thanks Norman!). Currently, I'm only using a spherical world model, but since I've written a little class to store geographical coordinates, this should be pretty easy to convert to something a little more complex. As for retaining the current local time, my original intention was to write some code of my own to parse the timezone values, but just before doing so, I found out that these functions are part of glibc already. So, after hacking around a little, I found out that localtime is determined through an environment var, that points to a file containing timezone info. So under linux, this stuff becomes pretty simple: 1. set up a fake environment var e.g. (pseudo code) char ** fake = { "europe/Amsterdam", 0}; environ = fake; 2. Get the time getlocaltime(); 3. Restore environ = oldEnviron; // point the environment to its origninal location I'm also pretty convinced that this won't work under other platforms, as those have a different mechanism for retrieving timezone info. So my idea would be to adapt the glibc code for use in flightgear, and also making the timezone informationfiles part of the fgfsbase package. After all, this is pretty close to my original idea of writing my own tz parser. This would save me quite some time. On the other hand, and this is my question: if somebody has a better idea, than I'd be very interested. Regards, Durk -- ----------------------------------------------------------------------- You can contact me at: pn_talsma(a)macmail.psy.uva.nl (work) talsma(a)uvapsy.psy.uva.nl (more work) d.talsma(a)direct.a2000.nl (home at last) Or visit my website at: http://people.a2000.nl/dtals ---------------------------------------------------------------------- "Dave, this conversation can serve no further purpose anymore, goodbye" - HAL 9000 - -- Please visit the FGFS web page: http://www.flightgear.org For help on using this list (especially unsubscribing), send a message to "fgfs-devel-request(a)flightgear.org" with a single line of text: "help".

2 1

timezone question
by Durk Talsma July 16, 1999

July 16, 1999

Hello, First of all, please let me introduce myself, my name is Durk Talsma, and I am currently helping in developing a GPL'ed Open Source Flightsimulator (http://www.flightgear.org) One of the things I'm currently working on is getting the local time right for any given location of an aircraft. Using your tzcode and tzdata packages, I started experimenting, and currently I am able to select the nearest timezone relative to an aircraft's position. I also found out that by faking a TZ environment variable, I'm capable of retrieving the right local time on my linux box. However, one of our goals is portability, and I don't know whether this trick will also work on other platforms, such as Windows or the Mac, using their native localtime() functions. So for this reason, I consider redistributing your timezone definition files with flightgear, along with a modified version of the glibc's localtime() function. For this reason, I have two questions. First, do you think it is necessary to do this, or is there a relatively simple way to get this information from the native OS'ses? And second, are we allowed to use your timezone information files, or code, and redistribute them with our project? By the way, the email adres I'm posting to right now was the only adress I could find for contacting you. Currently, I don't know who I'm sending this to, and I also don't know whether I'm sending this message to a private mail adress or a mailinglist. I also hope that my questions are appropriate to send to this adress. I've attached my latest message to the flightgear developers mailinglist below, to explain a little further what I'm working on. Thanks for reading. Best regards, Durk Talsma Hi, In part, this message is to give a small update on my timezone parsing code, and in part it is also intended to get some advice. First of all, it looks like I made good progress on the timezone parsing code. Currently, I'm able to parse the timezone database, and select the nearest timezone, based on the angle between my current location and the location of the timezone centerpoints, as described in the zone.tab file (thanks Norman!). Currently, I'm only using a spherical world model, but since I've written a little class to store geographical coordinates, this should be pretty easy to convert to something a little more complex. As for retaining the current local time, my original intention was to write some code of my own to parse the timezone values, but just before doing so, I found out that these functions are part of glibc already. So, after hacking around a little, I found out that localtime is determined through an environment var, that points to a file containing timezone info. So under linux, this stuff becomes pretty simple: 1. set up a fake environment var e.g. (pseudo code) char ** fake = { "europe/Amsterdam", 0}; environ = fake; 2. Get the time getlocaltime(); 3. Restore environ = oldEnviron; // point the environment to its origninal location I'm also pretty convinced that this won't work under other platforms, as those have a different mechanism for retrieving timezone info. So my idea would be to adapt the glibc code for use in flightgear, and also making the timezone informationfiles part of the fgfsbase package. After all, this is pretty close to my original idea of writing my own tz parser. This would save me quite some time. On the other hand, and this is my question: if somebody has a better idea, than I'd be very interested. Regards, Durk -- ----------------------------------------------------------------------- You can contact me at: pn_talsma(a)macmail.psy.uva.nl (work) talsma(a)uvapsy.psy.uva.nl (more work) d.talsma(a)direct.a2000.nl (home at last) Or visit my website at: http://people.a2000.nl/dtals ---------------------------------------------------------------------- "Dave, this conversation can serve no further purpose anymore, goodbye" - HAL 9000 - -- Please visit the FGFS web page: http://www.flightgear.org For help on using this list (especially unsubscribing), send a message to "fgfs-devel-request(a)flightgear.org" with a single line of text: "help".

1 0