From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a3358f1ef9d04e63
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-03-20 03:40:05 PST
Path: 
 supernews.google.com!sn-xit-03!supernews.com!freenix!sunqbc.risq.qc.ca!cyclone2.usenetserver.com!news-out.usenetserver.com!newsfeed.mesh.ad.jp!sjc1.nntp.concentric.net!newsfeed.concentric.net!global-news-master
From: Joseph P Vlietstra <joevl@concentric.net>
Newsgroups: comp.lang.ada
Subject: Re: Calendar - leap seconds
Date: 20 Mar 2001 11:34:41 GMT
Organization: Mojave Systems Corporation
Message-ID: <3AB742A8.CE77BC19@concentric.net>
References: <mailman.984930914.2293.comp.lang.ada@ada.eu.org>
Reply-To: joevl@concentric.net
NNTP-Posting-Host: 64.1.210.214
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.76 (Macintosh; U; PPC)
X-Accept-Language: en,pdf
Xref: supernews.google.com comp.lang.ada:5891
Date: 2001-03-20T11:34:41+00:00
List-Id: <comp.lang.ada>


On 17-Mar-01 singlespeeder wrote:
> How do I handle leap seconds using Ada.Calendar as the subtype
> Day_Duration doesn't have enough space for them?
>
> ARM 9.6(11):
> subtype Day_Duration is Duration range 0.0 ..  86_400.0;

Wilhelm Spickermann wrote:
> But, will it help? Does Your operating system still support leap
> seconds? AFAIK the BIG problem is, that most operating systems
> no longer support leap seconds, as POSIX has switched to ignoring
> them (<a time_t value of 536457599 shall correspond to "Wed Dec
> 31 23:59:59 UTC 1986">).

I wasn't able to login to the Austin group (joint Unix revision group)
document site from home (I get paid to work on this at work), but I
believe leap second support is still an open issue for the upcoming
revision.  The reason it's an open issue is that leap seconds may go
away.

>From the IAU Commission 31 (Time) website (http://www.bipm.org/IAU31):
> Since 1999, a number of organizations initiated a review on the
> future of the UTC system (insertion of leap seconds between TAI
> and UTC to keep |UT1-UTC|<0.9 s). The Consultative Committee for
> Time and Frequency (CCTF) in 1999 discussed the matter and the
> director of the BIPM sent letters to several international unions
> and navigation agencies. The International Union of Radio Science
> (URSI) created a WG, chaired by D.N. Matsakis (Commission 31 vice
> president). In 2000 the International Telecommunications Union (ITU)
> created a Special Rapporteur Group in the Working Party 7A, to study
> the new Question ITU-R[TF-QQQ](still in draft form) on 'The future
> of the UTC time scale'. The IAU 24th GA in 2000 passed Resolution B2
> to recommend the creation of a WG in collaboration with the URSI,
> ITU, BIPM, IERS and navigation agencies.

The leap second WG has not officially completed its work (and won't
until the next IAU General Assembly meeting in 2002), but my guess
is leap seconds will go away.  Each time BIPM introduces a leap
second there is a enormous amount of work involved.  Systems tied
to GPS receive the leap second update via the GPS almanac page,
but many telemetry systems need their leap second kernel file updated
or may even need a software update.  Why go through all of this effort
when civil timekeeping applications don't really care if UTC matches
UT1 and most spacecraft/astronomical applications use the TAI, J2000,
or the GPS linear timescale.