- tz - lists.iana.org

Bulletin C number 20
by iers＠hpopa.obspm.fr July 12, 2000

July 12, 2000

INTERNATIONAL EARTH ROTATION SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE BUREAU CENTRAL DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 Internet : iers(a)obspm.fr Paris, 12 Juillet 2000 Bulletin C 20 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI No positive leap second will be introduced at the end of December 2000. The difference between UTC and the International Atomic Time TAI is : from 1999 January 1, 0h UTC, until further notice : UTC-TAI = - 32 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Director Central Bureau of IERS

1 0

Re: Leap Second Report (fwd)
by Bradley White July 7, 2000

July 7, 2000

The Report of the URSI Commission J Working Group on the Leap Second read: > Appendix III. "Standard Reply" to queries concerning the questionnaire > > The response one person sent me is below, and it concerns Network Time > Protocol (NTP), which uses the internet to transfer time. > >> If leap seconds went away, the NTP community would worship the ground you >> walk on. Leap secs introduce a manual discontinuity in the NTP time scale. >> It takes a while to propagate leap secs through the hierarchy. While I concur on the unfortunate way in which NTP time stamps are encoded, I was running a sub-tree of NTP servers on an ado "right_only" system back in 1989 that, with the addition of a single time2posix() call, sailed through leap seconds without a hiccup (and without the need for any leap-second warning), so, I would proffer that leap seconds are not as much of a problem for NTP as many people seem to believe. Of course, leap-second warnings need to be replaced with the timely distribution of new ado zoneinfo data (which would also help with the ever changing summertime rules). I'm surprised that after all these years we do not have such a system in place, even if it was just a new DNS record type tied to names like New_York.America.zoneinfo.org. Bradley

1 0

Re: Leap Second Report
by Paul Eggert July 5, 2000

July 5, 2000

Date: Wed, 5 Jul 2000 14:32:15 GMT From: Demetrios N Matsakis <dnm(a)orion.usno.navy.mil> Report of the URSI Commission J Working Group on the Leap Second Just to put that report in its bureaucratic context: URSI is the International Union of Radio Science, a nongovernmental organization under the International Council for Science (ICSU). Commission J focuses on radio astronomy and remote sensing of celestial objects. Commission J set up the Working Group on the Leap Second in August of last year. Its job is to study the effect of halting leap second insertions into UTC, as proposed by McCarthy and Klepczynski. ICSU home page: http://www.icsu.org/ URSI home page: http://www.intec.rug.ac.be/Research/Projects/ursi/welcome.html Commission J info: http://www.intec.rug.ac.be/Research/Projects/ursi/Commissions.html Abstract of McCarthy & Klepczynski paper: http://www.gisdevelopment.net/reference/scie/s_t_41_50.htm#47

1 0

Leap Second Report (fwd)
by Markus Kuhn July 5, 2000

July 5, 2000

You might remember the USNO survey on the redefinition of UTC a few months ago. Here is their report on the results, which I guess might be of interest to some here. [My own reply then in a nutshell was not to abandon leap seconds, but perhaps to announce them much longer in advance (say 25 years), even if this means |UTC-UT1| > 900 ms sometimes temporarily.] Markus ------- Forwarded Message Date: Wed, 5 Jul 2000 14:23:34 GMT From: Demetrios N Matsakis <dnm(a)orion.usno.navy.mil> Subject: Leap Second Report Dear Respondee, Thank you for having responded to, or somehow been connected with, our questionnaire concerning the effects of a redefinition of UTC. If you are interested in pursuing this issue, we welcome you to join our listserv "chat group", http://clockdev.usno.navy.mil/archives/leapsecs.html. Demetrios Matsakis *************************************************************************** Report of the URSI Commission J Working Group on the Leap Second Date: July 2, 2000 Abstract and Conclusions An e-mail survey to find possible adverse effects of a redefinition of UTC has identified some possibly expensive or unsolvable problems involving software rewriting or checking, which are listed below. Although it was not possible to quantify the financial scale of resolving the software problems, the largest expenses appear to be for satellite systems, of which one estimate of several hundred thousand dollars was supplied. The quantity and quality of the responses opposed to a change indicate that those who favor any change must be prepared to make a very convincing argument to people and groups who initially will disagree with them. To further discuss this issue and inform the community of any developments, an archived electronic listserv has been set up. Anyone wishing to join can do so using http://clockdev.usno.navy.mil/archives/leapsecs.html. Introduction UTC (Coordinated Universal Time), which the public commonly confuses with Greenwich Mean Time, is computed by occasionally adding leap seconds to International Atomic Time (TAI). Since 1972, these leap seconds have been added on December 31 or June 30, at the rate of about one every 18 months, and serve to keep atomic time in step with the Earth's rotation. Although it is recommended that users use only TAI or UTC, as their needs indicate, many major navigation system have used times offset from TAI by fixed amounts. The most important of these is GPS, which is offset by 19 seconds from TAI. A segment of the international timing community has proposed a revision of the definition of UTC to avoid the discontinuities due to intermittent leap seconds. A discussion of the motivations for a change and of possible solutions has been published by McCarthy and Klepczynski in the Innovations Section of the November, 1999 issue of GPS World. The authors consider the most significant reason for a change to be keeping spread-spectrum communication systems and satellite navigation systems compatible with each other and with civil times. Another reason is the emerging need in the financial community to keep all computer time-stamps synchronized. In order to survey the effects of any action, an URSI Commission J Working Group (WG) was formed, whose purpose was to prepare this report and propose further actions. Methodology A questionnaire (Appendix I) was distributed as widely as seemed appropriate (Appendix II). The goal of the questionnaire was to find and categorize those operations that would be adversely affected should a change in UTC's computation be made. The questionnaire focused on the possibility of simply inserting no new leap seconds, although alternative solutions were also solicited. Over 200 responses were received, and no effort was made to separate the responses of URSI members from those of nonmembers. The principal object of the questionnaire was to find what systems would be adversely affected should a change be made in leap second procedures rather than to convince users of the need for a change or to take a vote. However, so many queries on these matters were received that a "standard reply" (Appendix III) was developed and distributed as appropriate. In the spirit of full disclosure, the number of responses in each category is given, but we caution that this was by no means an unbiased sampling of all who would be affected by the change. All responses were counted only once, with preference to the most practical grounds for objection. About half the responses that were received were opposed to any change, while one-fourth were in favor of a change, and one-fourth indifferent. I. Responses Opposed to Changes in the Status Quo A. The expense of rewriting software. Five responses suggested that contractors would have to be hired to scrutinize and adapt large amounts of code for operational satellite systems. Efforts were made to contact these responders for specific dollar amounts, and one off-the-cuff estimate of "several $100,000" was received. The impact on such systems would be lessened if any decision to redefine UTC were announced several years in advance. Twenty-six others indicated that software would be a serious problem - a very few of these were from people who did not seem to understand the proposal. There were 9 responses involving telescope control; one of these, from the Keck Observatory, provided a rough estimate of a few programmer- months. Others pointed out the problems computing eclipses and occultations, for telescope pointing by amateurs, or with code they had themselves written for professional-level projects such as speckle interferometry. One observatory indicated its station clock can not accommodate a large UT1-UTC correction. Fourteen more indicated that software issues would be a problem, but that they are probably solvable. Some of these actually indicated support for the change. B. Inherent inability to rewrite software to allow for |UT1-UTC| exceeding .9 seconds. Ten responses involved navigational software. Taking the example of a software product of the US Naval Observatory (USNO), pilots and sailors are given the option to input UT1-UTC. However, it is expected that many users would not understand this and enter 0, leading to noticeable errors within a decade. These are similar to the telescope-control problems covered above, except that one could not and should not expect the general public to ever understand these issues. Problems amateur astronomers might have are also included here, and were brought up by many responders in other contexts. One of the problems anticipated is that UT1-UTC could be applied with the wrong sign, just as the leap second is occasionally applied with the wrong sign. An example of "buffer overflow" problem would happen in NIST's WWV, WWVH and WWWB transmissions, which do not allow enough space for |UT1-UTC| to exceed .9 sec. Any users of these broadcasts who might need this information and who are unaware of the problem, decoding in hardware, or relying on old software would be adversely affected. Under the best of future circumstances only the sub-second (tenths) digit would be available, requiring the user to keep track of the digits to the left of the decimal point. Not tabulated is an informal comment seriously made to the Working Group's Chairman, by a respected and competent scientist from a non-western nation, that astrologers would be adversely affected. C. Philosophical Objections Eight thought this would confuse or antagonize the public, religious authorities, or even scientists - in essence because solar time is "true time". (In contrast, one responder in favor of a change thought this would help educate the public to the fact that Earth rotation is not "true" time). Three pointed out that legal complications might occur in countries where laws are specified in terms of solar time, or GMT (which has not existed for thirty years). Although one of these responders feared governments would not follow the scientist's lead, we find it difficult to believe that governments would, on their own, choose to add leap seconds. Others thought that any legal system flexible enough to handle daylight savings time and the past abandonment of GMT in favor of UTC would easily accommodate a seamless change in UTC's computation, especially if no other time standard were available. Some of the history of legal issues concerning past changes in time definition can be found in the book "Greenwich Time and Longitude" by Derek Howse. Three thought we should not adopt a system which will fail in the long run, even if that is a very distant time in the future. (It could be pointed out that all current time systems will eventually fail. Well before 2050 we could be routinely adding more than one leap second per year, and when we reach the point where a day is 48 hours long we would have to add a leap second every second. Even the Gregorian calendar will eventually need revision because in a few million years the Earth will rotate less than 365 times per year, and leap days will not be necessary.) Two thought this would deprive the timing community of free publicity when leap seconds are inserted. Thirty-eight expressed opposition, but gave no specific reason. Eleven of those also indicated that a problem would exist with their system, but did not specify it. Some of these pointed out that TAI was readily available, or indicated that they had seen no justification for a change. (We had intentionally provided no justification in the initial questionnaire, but two responders replied that they still believed there was not enough reason to change even after having read "standard response".) Four were against it because they thought problems would happen if some systems did not use the new system, and because they thought one would have to separate analyses based upon whether data were recorded with the current system or the old system. (We believe these to be based upon a misunderstanding of the "no new leap seconds" proposal, but entirely possible if the more drastic measure of re-defining SI, the International Second, were adopted.) II. Alternative Suggestions Five suggested that it would be better to redefine the second to be longer, add 1 second every 18 months forever, change on leap years or century-ends, or change when the number exceeded a fixed amount. These possibilities are also discussed in the GPS World Article. A suggestion was received to add enough "negative leap seconds" to bring UTC in line with GPS. However, a different responder pointed out that many of NASA's programs assume UT1-UTC always grows and that problems would happen with any change that would sometimes lead to a "negative leap second". (According to Dennis McCarthy of the USNO, this is possible even with the current system, but unlikely). It was also pointed out that rubidium atomic fountains or optical standards could lead to a redefinition of the second using an element other than cesium. If so, it could be redefined using a scale factor of sufficient magnitude to avoid the short-term need for leap seconds (As noted in the GPS World article, such a change would alter the values of those physical quantities that depend upon time.) One suggested that a redefined UTC should have a new name. III. Responses in favor of changing the current leap second procedures Forty-eight responses in favor were received, several from people who experienced minor problems now in handling leap seconds, such as confusion due to GPS time being currently 13 seconds offset from UTC and computer errors at the time of the leap seconds. Along with responses based upon reasons already covered in the GPS World Article, there were also three from the highly undersampled group of computer programmers, which pointed out the growing need to synchronize diverse computers to one second accuracy and the difficulties of doing so in an when dates of future leap seconds were unpredictable. Many of the responses indicated that periodic addition of leap seconds on a scheduled basis would also be acceptable. One of the responders, who was opposed to a change, suggested that leap seconds were not a problem because computer users could program an automatic extraction of the needed information from some publicly available source; however it must be pointed out that no one can guarantee that a given file, whether it be for leap seconds or for daily values of UT1-UTC (see part IV, below), will remain forever available in a given format or given IP address. Four responses were from people who indicated that the convenience in not having to update files every 18 months outweighed the expense and problems rewriting software. One of these suggested the use of sufficient negative leap seconds to bring UTC in line with TAI, and several noted that UT1-users easily incorporate the offsets due to time zones and daylight time. IV. Other Responses Forty-seven responders checked the "indifferent" option. Most indicated that there would be no problems with their system, or that the problems were small enough that they were indifferent to a change. Seven other responders indicated that the change would be okay if they could somehow reliably obtain UT1-UTC. (The USNO, as a sub-bureau of the IERS, freely provides this information on its web site, http://www. maia.usno.navy.mil, and via weekly emailings. Other organizations also provide this information.) Some responses tabulated here were phrased in the negative because the responders were apparently unaware that the information was available. One responder was concerned that the GPS system itself would be degraded for this reason, however this is not the case because GPS currently uses UT1-UTC values derived from USNO products. ________________________________________________________________________ Appendix I. Questionnaire It is being proposed to change the definition of Coordinated Universal Time (UTC) regarding the insertion of leap seconds, possibly even eliminating their use. Leap seconds are introduced so as to keep UTC synchronized (within 0.9 s) to the time scale determined from the Earth's rotation. Should no new leap seconds be inserted, solar time will diverge from atomic time at the rate of about 2 seconds every 3 years, and after about a century |UT1-UTC| would exceed 1 minute. Although no fundamental problems are anticipated, it is very likely that Y2K-like problems may result in software that assumes UT1=UTC, or |UT1-UTC|< some value, or whose input/output records use a field size that can only accommodate |UT1-UTC| values up to one second. To gather information, an URSI Commission J Working Group was formed, consisting of Don Backer, Wim. N. Brouw, Barry Clark, Irwin Shapiro, Ir. E. Van Lil, with Demetrios Matsakis being the chair. We would like to ask you to consult with the members of your institute who currently deal with UT1-UTC, and give us a considered response to the following two questions: A. If the appropriate international bodies decide to eliminate the insertion of new leap seconds, would you foresee any practical problems for your institution/instrument/observations? no ____ * yes ___ * possibly ____ (* please explain any known or possible problems) B. Would you be in favor of such a proposal? yes ____ no ____ indifferent ___ have better idea ___ (feel free to comment) C. Is there anyone else you would recommend we contact? (feel free to forward this email directly) I would appreciate your assistance, and a response by January 15 to dnm(a)orion.usno.navy.mil. I am attaching a list of institutions and persons contacted, except for 931 institutions whose emails were obtained from the AAS. I would like to apologize to anyone contacted twice, but also appreciate it if you would forward this email to anyone we have missed. Also, if you are an URSI Commission J national chair, we would appreciate your forwarding this email to your complete membership and in particular to the directors of observatories. Sincerely, Demetrios Matsakis ________________________________________________________________________ Dr. Demetrios N. Matsakis Director, Time Service Department (202) 762-1587 DSN 762-1587 U. S. Naval Observatory FAX (202) 762-1511 3450 Massachusetts Avenue NW dnm(a)orion.usno.navy.mil Washington DC, USA 20392-5420 ________________________________________________________________________ Appendix II. Distribution List Efforts were made to conduct an international survey, and responses were received from Europe, Japan, China, Australia, Canada, Russia, Saudi Arabia, Brazil, and other countries. The majority of the responses, however, were from the U.S. Commercial interests, such as satellite companies, were highly undersampled. The questionnaire asked people to forward it to others, and we know the following were contacted: 1. 128 prominent scientists, who were mostly URSI Commission J members and official representatives of institutions associated with URSI. 2. 27 URSI Commission J national chairs. 3. 931 Institutions extracted from a database kept by the American Astronomical Society, including many from outside the United States. Several hundred of those email addresses proved invalid. 4. All on the USNO Series 7 mailing list. 5. All on the "Gazette" mailing list of the International Earth Rotation Service (IERS). This would be expected to include most scientific groups that are directly involved with UT1. 6. One responder who worked in SETI indicated he had forwarded it to SETI circles. 7. The Internet Engineering Task Force's mail exploder. 8. One responder, who was against any change, indicated he had forwarded the questionnaire extensively around Jet Propulsion Labs (JPL). ________________________________________________________________________ Appendix III. "Standard Reply" to queries concerning the questionnaire Thank you for your response, which will be tabulated. Unix-technology willing, we also plan to send a copy of our report all responders. Many people have asked me why there is a move to rethink the leap seconds, with solutions such as (but not limited to) adding no new leap seconds. I unfortunately edited out some of the reasons from early drafts of the questionnaire, because I was afraid that people would not read a long email. Since then, I have developed the following "standard reply": 1.) Many high-tech navigation systems, particularly those using spread-spectrum techniques, can't handle leap seconds very well. GLONASS, the Russian equivalent to GPS, goes off-line for leap second adjustments. Also, problems can occur in interfacing between systems that handle leap seconds differently. There is also the practical problem of inserting a second every year and half - people often do it the wrong way. The response one person sent me is below, and it concerns Network Time Protocol (NTP), which uses the internet to transfer time. > If leap seconds went away, the NTP community would worship the ground you > walk on. Leap secs introduce a manual discontinuity in the NTP time scale. > It takes a while to propagate leap secs through the hierarchy. Leap seconds > are a tremendous headache in the NTP world because they cannot be predicted. > One must set a flag to indicate that one is coming. I think it is a very > true statement that all GPS users would vote against continuing leap seconds, > not just NTP users. Many telecommunications circuits use GPS or atomic clocks > to keep cellular phones in operation, and leap seconds are a nuisance to them > as well. 2.) I also received many comments about the effects on society when UT1 diverges. Note that we are talking about a minute in the next century. Society routinely handles a one-hour switch with every daily savings time, and a half-hour offset if they live at the edge of a time zone. By the time leap seconds add up to an hour, the world will be very different. If we have settled the solar system, a whole new scheme will probably have evolved. Even if we have not changed our system, society has enough slop in its timekeeping that people will slowly shift without even knowing it. More people will start showing up to work at 9:00 AM, and less at 8:30 AM, etc. 3) The "Innovations" section in November's GPS World is on this subject, and discusses other possibilities aside from "no new leap seconds". These are inserting larger discontinuities less frequently, inserting integer leap seconds at predefined times, simply using TAI, and redefining the length of the second. 4) It should be pointed out that UT1-UTC is readily available on the web. The USNO, as a subbureau of the International Rotation Service, makes this information available via a weekly mailing and from a web page at http://www.maia.usno.navy.mil, and other organizations also provide this service. 5) My final comment is not to worry about any "surprise" decisions - before/if the international bodies all decide to do this, it will be fully debated and publicized. My role, here, is simply to gather information. ------- End of Forwarded Message

1 0

Leap Second Report
by Demetrios N Matsakis July 5, 2000

July 5, 2000

Dear Respondee, Thank you for having responded to, or somehow been connected with, our questionnaire concerning the effects of a redefinition of UTC. If you are interested in pursuing this issue, we welcome you to join our listserv "chat group", http://clockdev.usno.navy.mil/archives/leapsecs.html. Demetrios Matsakis *************************************************************************** Report of the URSI Commission J Working Group on the Leap Second Date: July 2, 2000 Abstract and Conclusions An e-mail survey to find possible adverse effects of a redefinition of UTC has identified some possibly expensive or unsolvable problems involving software rewriting or checking, which are listed below. Although it was not possible to quantify the financial scale of resolving the software problems, the largest expenses appear to be for satellite systems, of which one estimate of several hundred thousand dollars was supplied. The quantity and quality of the responses opposed to a change indicate that those who favor any change must be prepared to make a very convincing argument to people and groups who initially will disagree with them. To further discuss this issue and inform the community of any developments, an archived electronic listserv has been set up. Anyone wishing to join can do so using http://clockdev.usno.navy.mil/archives/leapsecs.html. Introduction UTC (Coordinated Universal Time), which the public commonly confuses with Greenwich Mean Time, is computed by occasionally adding leap seconds to International Atomic Time (TAI). Since 1972, these leap seconds have been added on December 31 or June 30, at the rate of about one every 18 months, and serve to keep atomic time in step with the Earth's rotation. Although it is recommended that users use only TAI or UTC, as their needs indicate, many major navigation system have used times offset from TAI by fixed amounts. The most important of these is GPS, which is offset by 19 seconds from TAI. A segment of the international timing community has proposed a revision of the definition of UTC to avoid the discontinuities due to intermittent leap seconds. A discussion of the motivations for a change and of possible solutions has been published by McCarthy and Klepczynski in the Innovations Section of the November, 1999 issue of GPS World. The authors consider the most significant reason for a change to be keeping spread-spectrum communication systems and satellite navigation systems compatible with each other and with civil times. Another reason is the emerging need in the financial community to keep all computer time-stamps synchronized. In order to survey the effects of any action, an URSI Commission J Working Group (WG) was formed, whose purpose was to prepare this report and propose further actions. Methodology A questionnaire (Appendix I) was distributed as widely as seemed appropriate (Appendix II). The goal of the questionnaire was to find and categorize those operations that would be adversely affected should a change in UTC's computation be made. The questionnaire focused on the possibility of simply inserting no new leap seconds, although alternative solutions were also solicited. Over 200 responses were received, and no effort was made to separate the responses of URSI members from those of nonmembers. The principal object of the questionnaire was to find what systems would be adversely affected should a change be made in leap second procedures rather than to convince users of the need for a change or to take a vote. However, so many queries on these matters were received that a "standard reply" (Appendix III) was developed and distributed as appropriate. In the spirit of full disclosure, the number of responses in each category is given, but we caution that this was by no means an unbiased sampling of all who would be affected by the change. All responses were counted only once, with preference to the most practical grounds for objection. About half the responses that were received were opposed to any change, while one-fourth were in favor of a change, and one-fourth indifferent. I. Responses Opposed to Changes in the Status Quo A. The expense of rewriting software. Five responses suggested that contractors would have to be hired to scrutinize and adapt large amounts of code for operational satellite systems. Efforts were made to contact these responders for specific dollar amounts, and one off-the-cuff estimate of "several $100,000" was received. The impact on such systems would be lessened if any decision to redefine UTC were announced several years in advance. Twenty-six others indicated that software would be a serious problem - a very few of these were from people who did not seem to understand the proposal. There were 9 responses involving telescope control; one of these, from the Keck Observatory, provided a rough estimate of a few programmer- months. Others pointed out the problems computing eclipses and occultations, for telescope pointing by amateurs, or with code they had themselves written for professional-level projects such as speckle interferometry. One observatory indicated its station clock can not accommodate a large UT1-UTC correction. Fourteen more indicated that software issues would be a problem, but that they are probably solvable. Some of these actually indicated support for the change. B. Inherent inability to rewrite software to allow for |UT1-UTC| exceeding .9 seconds. Ten responses involved navigational software. Taking the example of a software product of the US Naval Observatory (USNO), pilots and sailors are given the option to input UT1-UTC. However, it is expected that many users would not understand this and enter 0, leading to noticeable errors within a decade. These are similar to the telescope-control problems covered above, except that one could not and should not expect the general public to ever understand these issues. Problems amateur astronomers might have are also included here, and were brought up by many responders in other contexts. One of the problems anticipated is that UT1-UTC could be applied with the wrong sign, just as the leap second is occasionally applied with the wrong sign. An example of "buffer overflow" problem would happen in NIST's WWV, WWVH and WWWB transmissions, which do not allow enough space for |UT1-UTC| to exceed .9 sec. Any users of these broadcasts who might need this information and who are unaware of the problem, decoding in hardware, or relying on old software would be adversely affected. Under the best of future circumstances only the sub-second (tenths) digit would be available, requiring the user to keep track of the digits to the left of the decimal point. Not tabulated is an informal comment seriously made to the Working Group's Chairman, by a respected and competent scientist from a non-western nation, that astrologers would be adversely affected. C. Philosophical Objections Eight thought this would confuse or antagonize the public, religious authorities, or even scientists - in essence because solar time is "true time". (In contrast, one responder in favor of a change thought this would help educate the public to the fact that Earth rotation is not "true" time). Three pointed out that legal complications might occur in countries where laws are specified in terms of solar time, or GMT (which has not existed for thirty years). Although one of these responders feared governments would not follow the scientist's lead, we find it difficult to believe that governments would, on their own, choose to add leap seconds. Others thought that any legal system flexible enough to handle daylight savings time and the past abandonment of GMT in favor of UTC would easily accommodate a seamless change in UTC's computation, especially if no other time standard were available. Some of the history of legal issues concerning past changes in time definition can be found in the book "Greenwich Time and Longitude" by Derek Howse. Three thought we should not adopt a system which will fail in the long run, even if that is a very distant time in the future. (It could be pointed out that all current time systems will eventually fail. Well before 2050 we could be routinely adding more than one leap second per year, and when we reach the point where a day is 48 hours long we would have to add a leap second every second. Even the Gregorian calendar will eventually need revision because in a few million years the Earth will rotate less than 365 times per year, and leap days will not be necessary.) Two thought this would deprive the timing community of free publicity when leap seconds are inserted. Thirty-eight expressed opposition, but gave no specific reason. Eleven of those also indicated that a problem would exist with their system, but did not specify it. Some of these pointed out that TAI was readily available, or indicated that they had seen no justification for a change. (We had intentionally provided no justification in the initial questionnaire, but two responders replied that they still believed there was not enough reason to change even after having read "standard response".) Four were against it because they thought problems would happen if some systems did not use the new system, and because they thought one would have to separate analyses based upon whether data were recorded with the current system or the old system. (We believe these to be based upon a misunderstanding of the "no new leap seconds" proposal, but entirely possible if the more drastic measure of re-defining SI, the International Second, were adopted.) II. Alternative Suggestions Five suggested that it would be better to redefine the second to be longer, add 1 second every 18 months forever, change on leap years or century-ends, or change when the number exceeded a fixed amount. These possibilities are also discussed in the GPS World Article. A suggestion was received to add enough "negative leap seconds" to bring UTC in line with GPS. However, a different responder pointed out that many of NASA's programs assume UT1-UTC always grows and that problems would happen with any change that would sometimes lead to a "negative leap second". (According to Dennis McCarthy of the USNO, this is possible even with the current system, but unlikely). It was also pointed out that rubidium atomic fountains or optical standards could lead to a redefinition of the second using an element other than cesium. If so, it could be redefined using a scale factor of sufficient magnitude to avoid the short-term need for leap seconds (As noted in the GPS World article, such a change would alter the values of those physical quantities that depend upon time.) One suggested that a redefined UTC should have a new name. III. Responses in favor of changing the current leap second procedures Forty-eight responses in favor were received, several from people who experienced minor problems now in handling leap seconds, such as confusion due to GPS time being currently 13 seconds offset from UTC and computer errors at the time of the leap seconds. Along with responses based upon reasons already covered in the GPS World Article, there were also three from the highly undersampled group of computer programmers, which pointed out the growing need to synchronize diverse computers to one second accuracy and the difficulties of doing so in an when dates of future leap seconds were unpredictable. Many of the responses indicated that periodic addition of leap seconds on a scheduled basis would also be acceptable. One of the responders, who was opposed to a change, suggested that leap seconds were not a problem because computer users could program an automatic extraction of the needed information from some publicly available source; however it must be pointed out that no one can guarantee that a given file, whether it be for leap seconds or for daily values of UT1-UTC (see part IV, below), will remain forever available in a given format or given IP address. Four responses were from people who indicated that the convenience in not having to update files every 18 months outweighed the expense and problems rewriting software. One of these suggested the use of sufficient negative leap seconds to bring UTC in line with TAI, and several noted that UT1-users easily incorporate the offsets due to time zones and daylight time. IV. Other Responses Forty-seven responders checked the "indifferent" option. Most indicated that there would be no problems with their system, or that the problems were small enough that they were indifferent to a change. Seven other responders indicated that the change would be okay if they could somehow reliably obtain UT1-UTC. (The USNO, as a sub-bureau of the IERS, freely provides this information on its web site, http://www. maia.usno.navy.mil, and via weekly emailings. Other organizations also provide this information.) Some responses tabulated here were phrased in the negative because the responders were apparently unaware that the information was available. One responder was concerned that the GPS system itself would be degraded for this reason, however this is not the case because GPS currently uses UT1-UTC values derived from USNO products. ________________________________________________________________________ Appendix I. Questionnaire It is being proposed to change the definition of Coordinated Universal Time (UTC) regarding the insertion of leap seconds, possibly even eliminating their use. Leap seconds are introduced so as to keep UTC synchronized (within 0.9 s) to the time scale determined from the Earth's rotation. Should no new leap seconds be inserted, solar time will diverge from atomic time at the rate of about 2 seconds every 3 years, and after about a century |UT1-UTC| would exceed 1 minute. Although no fundamental problems are anticipated, it is very likely that Y2K-like problems may result in software that assumes UT1=UTC, or |UT1-UTC|< some value, or whose input/output records use a field size that can only accommodate |UT1-UTC| values up to one second. To gather information, an URSI Commission J Working Group was formed, consisting of Don Backer, Wim. N. Brouw, Barry Clark, Irwin Shapiro, Ir. E. Van Lil, with Demetrios Matsakis being the chair. We would like to ask you to consult with the members of your institute who currently deal with UT1-UTC, and give us a considered response to the following two questions: A. If the appropriate international bodies decide to eliminate the insertion of new leap seconds, would you foresee any practical problems for your institution/instrument/observations? no ____ * yes ___ * possibly ____ (* please explain any known or possible problems) B. Would you be in favor of such a proposal? yes ____ no ____ indifferent ___ have better idea ___ (feel free to comment) C. Is there anyone else you would recommend we contact? (feel free to forward this email directly) I would appreciate your assistance, and a response by January 15 to dnm(a)orion.usno.navy.mil. I am attaching a list of institutions and persons contacted, except for 931 institutions whose emails were obtained from the AAS. I would like to apologize to anyone contacted twice, but also appreciate it if you would forward this email to anyone we have missed. Also, if you are an URSI Commission J national chair, we would appreciate your forwarding this email to your complete membership and in particular to the directors of observatories. Sincerely, Demetrios Matsakis ________________________________________________________________________ Dr. Demetrios N. Matsakis Director, Time Service Department (202) 762-1587 DSN 762-1587 U. S. Naval Observatory FAX (202) 762-1511 3450 Massachusetts Avenue NW dnm(a)orion.usno.navy.mil Washington DC, USA 20392-5420 ________________________________________________________________________ Appendix II. Distribution List Efforts were made to conduct an international survey, and responses were received from Europe, Japan, China, Australia, Canada, Russia, Saudi Arabia, Brazil, and other countries. The majority of the responses, however, were from the U.S. Commercial interests, such as satellite companies, were highly undersampled. The questionnaire asked people to forward it to others, and we know the following were contacted: 1. 128 prominent scientists, who were mostly URSI Commission J members and official representatives of institutions associated with URSI. 2. 27 URSI Commission J national chairs. 3. 931 Institutions extracted from a database kept by the American Astronomical Society, including many from outside the United States. Several hundred of those email addresses proved invalid. 4. All on the USNO Series 7 mailing list. 5. All on the "Gazette" mailing list of the International Earth Rotation Service (IERS). This would be expected to include most scientific groups that are directly involved with UT1. 6. One responder who worked in SETI indicated he had forwarded it to SETI circles. 7. The Internet Engineering Task Force's mail exploder. 8. One responder, who was against any change, indicated he had forwarded the questionnaire extensively around Jet Propulsion Labs (JPL). ________________________________________________________________________ Appendix III. "Standard Reply" to queries concerning the questionnaire Thank you for your response, which will be tabulated. Unix-technology willing, we also plan to send a copy of our report all responders. Many people have asked me why there is a move to rethink the leap seconds, with solutions such as (but not limited to) adding no new leap seconds. I unfortunately edited out some of the reasons from early drafts of the questionnaire, because I was afraid that people would not read a long email. Since then, I have developed the following "standard reply": 1.) Many high-tech navigation systems, particularly those using spread-spectrum techniques, can't handle leap seconds very well. GLONASS, the Russian equivalent to GPS, goes off-line for leap second adjustments. Also, problems can occur in interfacing between systems that handle leap seconds differently. There is also the practical problem of inserting a second every year and half - people often do it the wrong way. The response one person sent me is below, and it concerns Network Time Protocol (NTP), which uses the internet to transfer time. > If leap seconds went away, the NTP community would worship the ground you > walk on. Leap secs introduce a manual discontinuity in the NTP time scale. > It takes a while to propagate leap secs through the hierarchy. Leap seconds > are a tremendous headache in the NTP world because they cannot be predicted. > One must set a flag to indicate that one is coming. I think it is a very > true statement that all GPS users would vote against continuing leap seconds, > not just NTP users. Many telecommunications circuits use GPS or atomic clocks > to keep cellular phones in operation, and leap seconds are a nuisance to them > as well. 2.) I also received many comments about the effects on society when UT1 diverges. Note that we are talking about a minute in the next century. Society routinely handles a one-hour switch with every daily savings time, and a half-hour offset if they live at the edge of a time zone. By the time leap seconds add up to an hour, the world will be very different. If we have settled the solar system, a whole new scheme will probably have evolved. Even if we have not changed our system, society has enough slop in its timekeeping that people will slowly shift without even knowing it. More people will start showing up to work at 9:00 AM, and less at 8:30 AM, etc. 3) The "Innovations" section in November's GPS World is on this subject, and discusses other possibilities aside from "no new leap seconds". These are inserting larger discontinuities less frequently, inserting integer leap seconds at predefined times, simply using TAI, and redefining the length of the second. 4) It should be pointed out that UT1-UTC is readily available on the web. The USNO, as a subbureau of the International Rotation Service, makes this information available via a weekly mailing and from a web page at http://www.maia.usno.navy.mil, and other organizations also provide this service. 5) My final comment is not to worry about any "surprise" decisions - before/if the international bodies all decide to do this, it will be fully debated and publicized. My role, here, is simply to gather information.

1 0

FW: Time zone info in Tasmania for year 2000
by Olson, Arthur David (NCI) July 3, 2000

July 3, 2000

Sim Alam is not on the time zone mailing list; direct replies appropriately. --ado > -----Original Message----- > From: Alam, Sim [SMTP:Sim.Alam@Central.tased.edu.au] > Sent: Monday, July 03, 2000 12:35 AM > To: 'tz(a)elsie.nci.nih.gov' > Subject: Time zone info in Tasmania for year 2000 > > Hi, > > Is the Time zone entry for the Year 2000 wrong in the Australasia time > zone > file version 7.46? The last sunday in August 2000 is the 27th and not the > 26th. Shouldn't the following be the right entries? > Rule AN 2000 only - Aug 27 2:00s 1:00 - > Rule AN 2001 max - Oct lastSun 2:00s 1:00 - > > Also, in the 7.46 version of the Australasia file Tasmania does not have > any > entries for 2000 (see > http://www.thelaw.tas.gov.au/fragview/42++1968+GS3A@EN+2000070300 for more > info) : > > Regards, > Sim Alam > > Information Management Branch > Department of Education > Level 2, 73 Murray Street > Hobart, Tasmania 7000 > Ph: +61 3 6233 6900 > Fax: +61 3 6233 6969

2 1

Long./lat. data
by Ralf Neubersch July 3, 2000

July 3, 2000

Does anybody know where I can get the timezones in longitude/latitude format to overlay them on generated maps? \Ralf

1 0

Time zone info in Tasmania for year 2000
by Alam, Sim July 3, 2000

July 3, 2000

Hi, Is the Time zone entry for the Year 2000 wrong in the Australasia time zone file version 7.46? The last sunday in August 2000 is the 27th and not the 26th. Shouldn't the following be the right entries? Rule AN 2000 only - Aug 27 2:00s 1:00 - Rule AN 2001 max - Oct lastSun 2:00s 1:00 - Also, in the 7.46 version of the Australasia file Tasmania does not have any entries for 2000 (see http://www.thelaw.tas.gov.au/fragview/42++1968+GS3A@EN+2000070300 for more info) : Regards, Sim Alam Information Management Branch Department of Education Level 2, 73 Murray Street Hobart, Tasmania 7000 Ph: +61 3 6233 6900 Fax: +61 3 6233 6969

1 0

Time Zone Editor
by Jesper Nørgaard July 1, 2000

July 1, 2000

The short version: Cut the below text to a text file and save it as tzsydney.reg. REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Time Zones\Sydney] "Display"="(GMT+10:00) Melbourne, Sydney" "Dlt"="Sydney Daylight Time" "Std"="Sydney Standard Time" "TZI"=hex:a8,fd,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,03,00,00,00,05,00,03,00,00,\ 00,00,00,00,00,00,00,08,00,00,00,05,00,02,00,00,00,00,00,00,00 "MapID"="20,21" Now double click on tzsydney.reg which will load this to the registry. You should now be able to open Date/Time from Windows Settings and select "(GMT+10:00) Melbourne, Sydney" and click on the optionsbutton below so that Windows is handling daylight saving automatically. That is all there is to it! :-) First of all let me say I haven't tried it in Windows NT, only in Windows 95. According to documentation probably the key above would be [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Sydney] instead. Try it for yourself. I did use tzedit.exe to view the time zones in a Windows NT computer, and that worked fine. I did not try to update with it on the Windows NT computer. As mentioned in earlier mails Mickeysoft has made a program called Windows Time Zone Editor which handles these matters without having to fumble around with the registry editor poking in hexadecimal values. I have created a registry file with all known timezones that we know on the mailing list. If you are interested in this, please download the file http://timezone50.homepage.com/tzedit.zip which contains the following: tzedit.exe The Time Zone Editor tzedit.hlp Help file for the program tzedit.txt A text file I prepared with the information about which time zone in tznew.reg corresponds to which country. tznew.reg Registry file with all the timezones documented in tzedit.txt and the correct start and end times for year 2000. You can either import the full file into the registry, or copy-and-paste the time zone(s) you want first to another *.REG file, and then double click on that. These files can be used for any purpose you have, its "use-at-will-ware" :-) I have investigated this to include in my PC program Time Zone Converter (see also http://timezone50.homepage.com) but that hasn't been included yet. You might want to try the PC program though. Just to continue the discussion, I have noticed a problem at least in Windows 95. I don't know if it is also a problem in Windows 98 or Windows NT. I would be grateful if anybody knows or can investigate this on these machines. The problem: When using a time zone that has automatic daylight savings handled by Windows 95, then everything works fine if you turn off your computer every night before going to bed as any good Mickeysoftian :-) However, if you keep it on 24 hours a day, then there is a problem when leaving daylight saving. Lets say that at 3 o'clock in the morning Windows turn back the clock to 2 o'clock as it should. Then it was supposed to let time run ahead until 3 o'clock again, but now not turn the clock 1 hour back (since it reached 3 o'clock for the second time) but continue. Unfortunately it goes into an "endless" loop repeating to turn it back to 2 o'clock. The only way to leave this diabolic situation is to turn time ahead to after 3 o'clock, but at this point the registry has been screwed up. Any information about this will be of interest. Regards, Jesper Nørgaard Email: jnorgard(a)df1.telmex.net.mx Programador/Analista CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT, Lisboa 27, 06600 Mexico, D.F. Tel.: +52 (5) 7267541 ext. 1374 Fax: +52 (5) 7267558 Tel. Casa: 53-10-05-95 ó 53-10-97-78 CIMMYT home page: http://www.cimmyt.mx

1 0

TimesOwn - World Time Zone Clock
by Tom Hingston June 30, 2000

June 30, 2000

Hi I have been to your site and wondered if you would consider adding this software to your site. Timesown - World clock and time zone difference calculator A program to tell you what time it is now, in any time zone in the world. You add the countries or your friends names, enter the time difference (once), and you can keep it in your system tray, on the task bar, for easy reach. Great if you use chat programs like ICQ or Messenger, or if you do business with other countries. You will always know what the time is where your friends and contacts live. Features a.. Includes a 'Look up' that calculates most time differences for you. b.. 1 click daylight savings correction for you. c.. Simple installation and easy to use. d.. User choice - customise it to list cities or countries, or even your friends names. e.. List as many places as you want. f.. Auto refresh option - keeps times always up-to-date. g.. Open it as you want it, or leave it in the system tray (by the clock) for easy access. View it and download it from http://hingston.yi.org/chequers/timesown.html direct download http://hingston.yi.org/chequers/timesownzip.exe Shareware Windows95/98/NT/2000 Thanks for your consideration Tom Hingston cheq(a)xtra.co.nz

1 0

RE: FW: Romance Time (forwarded with permission)
by Dave Turnbull June 30, 2000

June 30, 2000

Hi re "makes me wonder whether that [Windows NT registry] could be edited instead." For Windows NT see the MS note Q176513 (in the MSDN Lbrary CDs or on the web at http://support.microsoft.com/support/kb/articles/Q176/5/13.ASP) for an example of ading a timezone to the list in Windows which can be selected from the Time/Date control panel applet. Although it doesn't talk about it in the article I expect you could then save that new subtree (as a .reg file) which can be "executed" on a(nother) user's computer. Dave Turnbull PS Apologies if I've broken etiquette by replying to the wrong names, I'm new on this mailing list. Point me to the FAQ! > -----Original Message----- > From: Alex LIVINGSTON [SMTP:alex@agsm.edu.au] > Sent: 30 June 2000 04:25 > To: Antoine Leca > Cc: tz(a)elsie.nci.nih.gov; Tim Stratford > Subject: Re: FW: Romance Time (forwarded with permission) > > At 18:49 +0200 2000-06-29, Antoine Leca wrote: > >> > From: Tim Stratford [SMTP:TStratford@oneworldsoftware.com] > >> > Sent: Thursday, June 29, 2000 10:44 AM > >> > To: 'ado(a)elsie.nci.nih.gov' > >> > Subject: One quick question please.... > >> > > >> > Dear Arthur David Olson, > >> > Today I was doing research concerning a time zone or aspect of > time > >> > called Romance Time. The research is for one of our software > customers > >> > and we cannot find much pertaining to the subject at all. Is their > some > >> > information which you could supply me about the subject or some > resources > >> > which I could further research? Thank you very much for your time > and > >> > cooperation. > > > >'Romance' is the name used for Europe/Paris and Europe/Madrid > >areas in the Windows time zone database. > > > > > >Hope it helps, > > > >Antoine > > I'm sure someone'll tell me if this is initiating a discussion that is not > relevant to the tz mailing list, but it involves keeping track of time on > computers... > > I'm not a Windows afficionado, and I doubt I'll ever be, but the > installation where I work now consists mostly of machines running one > version of Windows or another (at this stage mostly Windows NT 4). > > As southeastern Australia (where I am) is starting daylight saving > considerably earlier this year than hitherto, I was concerned to know how > all our Windows boxes (especially our servers) could be made to behave > civilly in this circumstance. I asked a colleage this week about whether a > suitable patch or update from Microsoft (for NT) was possible, but he said > only service packs, which require bringing down the machine, were issued. > The only way we could see of getting around the problem was by setting the > machines' time zone to "(GMT +11:00) Magadan, Solomon Is., New Caledonia" > until the date when NT thinks daylight saving starts in our zone ("... > Canberra, Sydney, Melbourne", from memory). Your (Antoine's) mention of > "the Windows time zone database" makes me wonder whether that could be > edited instead. > > I'd also be interested to know if anyone's worked out how to patch Mac > OS's > Date & Time control panel (presumably its 'cty#' resource) to effect the > same adjustment. > > Thanks for your attention. > > --Alex > > _______________ > Alex LIVINGSTON > Macintosh and Lotus Notes Support / Information Technology (IT) > Australian Graduate School of Management (AGSM) > UNSW SYDNEY NSW 2052 / Australia > > Facsimile: +61 2 9931-9349 / Telephone: +61 2 9931-9264 > Time : UTC+11---[last Mar. Sun.---UTC+10---[last Aug. Sun.---UTC+11--- > > At midday today, Friday, June 30, > time since epoch (1-1-1 at 00:00:00) is > 730300.5 days = 1999.49485616 average Gregorian years > time until 3rd millennium, 21st century, 201st decade, 2001st year is > 184.5 days = .50514384 average Gregorian years >

3 2

Re[2]: FW: Romance Time (forwarded with permission)
by tony.milton＠bnpparibas.com June 30, 2000

June 30, 2000

There is a timezone editor in the NT resource kit. Tony. Internet From: Peter.Hullah(a)eurocontrol.fr on 30/06/2000 08:56 To: alex cc: Antoine.Leca, tz, TStratford bcc: Tony Milton Subject: Re: FW: Romance Time (forwarded with permission) The following URL gives the official Mickeysoft solution to changes in Australian time zones this year. http://www.microsoft.com/australia/support/timezone/2000.htm To change any other timezone problems you have to edit the registry, modifying binary values that I can't find any documentation on. But then that's Mickeysoft for you - can't trust users to fix their bugs for them and won't do it for themselves. Pete PS Where did MS get "Romance Daylight Time" from anyway? Just another of their we-dont-care-what-the-rest-of-the-world-has-as-a-standard-this-is-ours attitudes? Alex LIVINGSTON wrote: > At 18:49 +0200 2000-06-29, Antoine Leca wrote: > >> > From: Tim Stratford [SMTP:TStratford@oneworldsoftware.com] > >> > Sent: Thursday, June 29, 2000 10:44 AM > >> > To: 'ado(a)elsie.nci.nih.gov' > >> > Subject: One quick question please.... > >> > > >> > Dear Arthur David Olson, > >> > Today I was doing research concerning a time zone or aspect of time > >> > called Romance Time. The research is for one of our software customers > >> > and we cannot find much pertaining to the subject at all. Is their some > >> > information which you could supply me about the subject or some resources > >> > which I could further research? Thank you very much for your time and > >> > cooperation. > > > >'Romance' is the name used for Europe/Paris and Europe/Madrid > >areas in the Windows time zone database. > > > > > >Hope it helps, > > > >Antoine > > I'm sure someone'll tell me if this is initiating a discussion that is not > relevant to the tz mailing list, but it involves keeping track of time on > computers... > > I'm not a Windows afficionado, and I doubt I'll ever be, but the > installation where I work now consists mostly of machines running one > version of Windows or another (at this stage mostly Windows NT 4). > > As southeastern Australia (where I am) is starting daylight saving > considerably earlier this year than hitherto, I was concerned to know how > all our Windows boxes (especially our servers) could be made to behave > civilly in this circumstance. I asked a colleage this week about whether a > suitable patch or update from Microsoft (for NT) was possible, but he said > only service packs, which require bringing down the machine, were issued. > The only way we could see of getting around the problem was by setting the > machines' time zone to "(GMT +11:00) Magadan, Solomon Is., New Caledonia" > until the date when NT thinks daylight saving starts in our zone ("... > Canberra, Sydney, Melbourne", from memory). Your (Antoine's) mention of > "the Windows time zone database" makes me wonder whether that could be > edited instead. > > I'd also be interested to know if anyone's worked out how to patch Mac OS's > Date & Time control panel (presumably its 'cty#' resource) to effect the > same adjustment. > > Thanks for your attention. > > --Alex > > _______________ > Alex LIVINGSTON > Macintosh and Lotus Notes Support / Information Technology (IT) > Australian Graduate School of Management (AGSM) > UNSW SYDNEY NSW 2052 / Australia > > Facsimile: +61 2 9931-9349 / Telephone: +61 2 9931-9264 > Time : UTC+11---[last Mar. Sun.---UTC+10---[last Aug. Sun.---UTC+11--- > > At midday today, Friday, June 30, > time since epoch (1-1-1 at 00:00:00) is > 730300.5 days = 1999.49485616 average Gregorian years > time until 3rd millennium, 21st century, 201st decade, 2001st year is > 184.5 days = .50514384 average Gregorian years -- Peter H.C. Hullah Environment Business Area mailto:Peter.Hullah@eurocontrol.fr EUROCONTROL Experimental Centre Phone: +33 1 69 88 75 49 Centre du Bois des Bordes, BP15, Fax: +33 1 60 85 15 04 91222 BRETIGNY SUR ORGE CEDEX France ___________________________________________________________ This message and any attachments (the "message") are intended solely for the addressees and are confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or patial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. --------------------------------------------- Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. ___________________________________________________________

1 0

FW: Romance Time (forwarded with permission)
by Olson, Arthur David (NCI) June 30, 2000

June 30, 2000

Tim Stratford is not on the time zone mailing list; direct replies appropriately. --ado > -----Original Message----- > From: Tim Stratford [SMTP:TStratford@oneworldsoftware.com] > Sent: Thursday, June 29, 2000 10:44 AM > To: 'ado(a)elsie.nci.nih.gov' > Subject: One quick question please.... > > Dear Arthur David Olson, > Today I was doing research concerning a time zone or aspect of time > called Romance Time. The research is for one of our software customers > and > we cannot find much pertaining to the subject at all. Is their some > information which you could supply me about the subject or some resources > which I could further research? Thank you very much for your time and > cooperation. > > Sincerely, > > Tim Stratford > ONEWORLD Software Solutions > Tel. # (617)621-9966 > Fax # (617)621-9977

4 3

Timezones
by David Usher June 29, 2000

June 29, 2000

Hello, Could you please tell me how often the timezone database is updated and could you subscibe me to the mailing list. Regards, David usher

1 0

FW: question
by Olson, Arthur David (NCI) June 22, 2000

June 22, 2000

> -----Original Message----- > From: Brian Kardell [SMTP:bkardell@lynxsys.com] > Sent: Thursday, June 22, 2000 4:30 PM > To: Olson, Arthur David (NCI) > Subject: question > ... > I am currently some developing software that > requires me to figure out timezone/deviation from UTC > and it also needs to be correct with at least the vast majority > of DST issues. We are writting some Java code and I'm > wondering if you know of any databases/libraries/APIs that we > could use/purchase to help this happen - based on either > a telephone number or city/state/country type information... > Any help or advice that you could provide would be greatly > appreciated. Thanks. > > Brian Kardell > Software Engineer > Lynx Systems > 187 St. Paul Street > Burlington, VT 05401 > (802) 651 - 7369

2 1

FW: Corrections to australasia zoneinfo
by Olson, Arthur David (NCI) June 19, 2000

June 19, 2000

Nickolas is not on the time zone list; be sure to direct replies appropriately. --ado > -----Original Message----- > From: Jeitner, Nickolas [SMTP:nickolas.jeitner@eds.com] > Sent: Sunday, June 18, 2000 10:34 PM > To: 'tz(a)elsie.nci.nih.gov' > Subject: Corrections to australasia zoneinfo > > The zoneinfo file I found on munnari.oz.au makes an assumption that South > Australia will follow the eastern states in moving daylight savings > forward > and correspondingly, Tasmania would not. This logic is reversed and it's > actually Tasmania which will follow the other states and South Australian > which wont be changing. > > I've included a diff patch which reflects these changes, please feel free > to > use then as you see fit. I had confirmed the time zone information as best > as I can, including the following SA government site: > > http://www.sacentral.sa.gov.au/information/daylite.htm > > Patch to apply as follows: > > 71c71 > < Rule AS 1987 1999 - Oct lastSun 2:00s 1:00 - > --- > > Rule AS 1987 max - Oct lastSun 2:00s 1:00 - > 78,79d77 > < Rule AS 2000 only - Aug lastSun 2:00s 1:00 - > < Rule AS 2001 max - Oct lastSun 2:00s 1:00 - > 100c98 > < Rule AT 1991 max - Oct Sun>=1 2:00s 1:00 - > --- > > Rule AT 1991 1999 - Oct Sun>=1 2:00s 1:00 - > 101a100,102 > > Rule AT 2000 only - Aug LastSun 2:00s 1:00 - > > Rule AT 2001 max - Oct Sun>=1 2:00s 1:00 - > > > > Regards Nick > > Nick Jeitner Ph: +61 8 8301 5342 > EDS, Client/Server Eng. Fx: +61 8 8301 5399 > 65 Conyngham St Glenside Email: Nickolas.Jeitner(a)eds.com

1 0

Corrections to australasia zoneinfo
by Jeitner, Nickolas June 19, 2000

June 19, 2000

The zoneinfo file I found on munnari.oz.au makes an assumption that South Australia will follow the eastern states in moving daylight savings forward and correspondingly, Tasmania would not. This logic is reversed and it's actually Tasmania which will follow the other states and South Australian which wont be changing. I've included a diff patch which reflects these changes, please feel free to use then as you see fit. I had confirmed the time zone information as best as I can, including the following SA government site: http://www.sacentral.sa.gov.au/information/daylite.htm Patch to apply as follows: 71c71 < Rule AS 1987 1999 - Oct lastSun 2:00s 1:00 - --- > Rule AS 1987 max - Oct lastSun 2:00s 1:00 - 78,79d77 < Rule AS 2000 only - Aug lastSun 2:00s 1:00 - < Rule AS 2001 max - Oct lastSun 2:00s 1:00 - 100c98 < Rule AT 1991 max - Oct Sun>=1 2:00s 1:00 - --- > Rule AT 1991 1999 - Oct Sun>=1 2:00s 1:00 - 101a100,102 > Rule AT 2000 only - Aug LastSun 2:00s 1:00 - > Rule AT 2001 max - Oct Sun>=1 2:00s 1:00 - > Regards Nick Nick Jeitner Ph: +61 8 8301 5342 EDS, Client/Server Eng. Fx: +61 8 8301 5399 65 Conyngham St Glenside Email: Nickolas.Jeitner(a)eds.com

1 0

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