Leap Seconds

Leap Seconds

[Marin David Condic]

I need to do some computations involving seconds between two dates. AFAIK,
there is nothing specific in the ARM related to the package Calendar that an
implementation is required to account for leap seconds. Consider the
following computation:

Some_Duration := Time_Of (1996, 1, 1, 0.0) - Time_Of (1980, 1, 6, 0.0) ;

I'd guess that an implementation having a big enough Duration would almost
certainly consider leap years in this computation, but leap seconds might
not be required or implemented. Across relatively small spans of time, it
probably doesn't matter and certainly if one is only doing relative timing
(deltas) it doesn't matter at all. However, across larger spans, it could be
enough to make a difference. Does anyone know if it is required?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Leap Seconds

[Tucker Taft]

Marin David Condic wrote:
> 
> I need to do some computations involving seconds between two dates. AFAIK,
> there is nothing specific in the ARM related to the package Calendar that an
> implementation is required to account for leap seconds. Consider the
> following computation:
> 
> Some_Duration := Time_Of (1996, 1, 1, 0.0) - Time_Of (1980, 1, 6, 0.0) ;
> 
> I'd guess that an implementation having a big enough Duration would almost
> certainly consider leap years in this computation, but leap seconds might
> not be required or implemented. Across relatively small spans of time, it
> probably doesn't matter and certainly if one is only doing relative timing
> (deltas) it doesn't matter at all. However, across larger spans, it could be
> enough to make a difference. Does anyone know if it is required?

There is no requirement to support leap seconds.
I would guess it is safe to say that leap seconds
are *not* supported in any Ada implementation.
There might even be ACATS/ACVC tests that are actively unfriendly
to leap seconds, though I don't know for sure.

> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/

-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Burlington, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/services/ebusiness_applications.html)

Re: Leap Seconds

[Marin David Condic]

Further research into leap-seconds indicates that effectively, they are
unpredictable. The International Earth Rotation Service sort of announces
them whenever they think it is necessary and they can be positive or
negative. Hence, unless one has a lookup table for leap-seconds in the past,
it would not be possible to know when they existed. (The first happened in
1972) It is even more problematic if you are calculating some time in the
future since you don't know when they happen. (Customarily, leap-seconds are
announced in December or June, but they need not happen every year.)

While a handful of seconds over a number of years may not be a big deal in
most cases, I could easily imagine where they might make a difference.
(Especially when trying to sync up with something else that is using a time
base somewhere in the past and wondering if it counts the leap seconds and
you don't. Source A counts them, source B doesn't and you're in the middle
trying to figure out 'does anybody really know what time it is?')

More info at:

http://maia.usno.navy.mil/eo/leapsec.html

Now I'm wondering what I'm supposed to do with the requirement that I count
them??? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Tucker Taft" <stt@averstar.com> wrote in message
news:3B0ED67B.E40A4E06@averstar.com...
>
> There is no requirement to support leap seconds.
> I would guess it is safe to say that leap seconds
> are *not* supported in any Ada implementation.
> There might even be ACATS/ACVC tests that are actively unfriendly
> to leap seconds, though I don't know for sure.
>

Re: Leap Seconds

[Ted Dennison]

In article <9f0ciq$itb$1@nh.pace.co.uk>, Marin David Condic says...
>
>Further research into leap-seconds indicates that effectively, they are
>unpredictable. The International Earth Rotation Service sort of announces
..
>Now I'm wondering what I'm supposed to do with the requirement that I count
>them??? :-)

I once worked on a project where we had a requirement to never loose an
inter-process message, and to hold the client and all recipients until we knew
it was received by all designated recipients. The more astute of you out there
will immediately recognise this as a variant the "Byzantine Generals Problem".
We were not so astute, unfortunatly.

I find the best thing to do in these situations is to find some desirable extra
that you were going to add anyway, or would be trivial to add (there's always a
few of those once development starts), and "trade" it for the impossible
requirement with your customer. Do this after pointing out to them that they
have asked the physically impossible, preferably using supporting material from
scholarly sources (eg: the website you mentioned). This is also a good way to
get rid of other requirements that are way more expensive to implement than they
are worth (in that case, you use a good estimate of the financial impact of
adding the feature as your supporting material).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Leap Seconds

[Marin David Condic]

Well, its actually a "requirement" that is spelled out in a standards
document that is not (yet) accepted by the FCC (AFIK). WRT
"event_start_time", the standard says: "A 32-bit unsigned integer quantity
representing the start time of this alert event as the number of seconds
since 00 hours UTC, January 6th, 1980 with the count of interleaving leap
seconds included."

The situation is this: The source *may* be able to produce that time base &
interleaving leap seconds. It would require a leap-second table that is
periodically updated as new leap seconds happen - with the possibility that
there is some delay between the leap-second and the table update. (In this
app it isn't critical, but it might one day be critical in some other
area...) The local time base is different and won't have access to any sort
of leap-second update table. (Again, in this situation being off by a few
seconds is not a big deal - but it might be in other parts of the
application.) I can correct with a constant plus a "tuning" value sent from
the source - if available - that represents leap seconds & hence we can be
on the same time base. Hence a solution does exist.

Back on topic: Since Ada doesn't promise anything about leap-seconds in the
standard, I couldn't use it at the source or destination and just trust the
compiler to get it right. Ada *might* get the leap seconds right if, for
example, its time comes from the operating system and the OS is doing some
sort of correction. I *know* my client side isn't going to have anything
like that, so Ada unfortunately doesn't provide me with a nice, automatic
answer.

MDC

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:tKPQ6.3762$rn5.204359@www.newsranger.com...
> In article <9f0ciq$itb$1@nh.pace.co.uk>, Marin David Condic says...
> >
> >Further research into leap-seconds indicates that effectively, they are
> >unpredictable. The International Earth Rotation Service sort of announces
> ..
> >Now I'm wondering what I'm supposed to do with the requirement that I
count
> >them??? :-)
>
> I once worked on a project where we had a requirement to never loose an
> inter-process message, and to hold the client and all recipients until we
knew
> it was received by all designated recipients. The more astute of you out
there
> will immediately recognise this as a variant the "Byzantine Generals
Problem".
> We were not so astute, unfortunatly.
>
> I find the best thing to do in these situations is to find some desirable
extra
> that you were going to add anyway, or would be trivial to add (there's
always a
> few of those once development starts), and "trade" it for the impossible
> requirement with your customer. Do this after pointing out to them that
they
> have asked the physically impossible, preferably using supporting material
from
> scholarly sources (eg: the website you mentioned). This is also a good way
to
> get rid of other requirements that are way more expensive to implement
than they
> are worth (in that case, you use a good estimate of the financial impact
of
> adding the feature as your supporting material).
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Leap Seconds

[tmoran]

> so Ada unfortunately doesn't provide me with a nice, automatic answer.
ARM 9.6(22) "The time base associated with the type Time of package
Calendar is implementation defined."

Re: Leap Seconds

[Marin David Condic]

Well, the time base is one thing. The other part being the delta between
times. From one epoc to another, you just need to add an appropriate number
of seconds for adjustment of the time base. If leap seconds figure into it,
you need to include that in your adjustment of epoc and also of any
calculations between two times. The standard doesn't say anything about epoc
but, more importantly in this case, it doesn't say anything about deltas
between times. That's the particular problem I'm sorting out at the moment.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:B0SQ6.45053$%i7.35248112@news1.rdc1.sfba.home.com...
> > so Ada unfortunately doesn't provide me with a nice, automatic answer.
> ARM 9.6(22) "The time base associated with the type Time of package
> Calendar is implementation defined."

Re: Leap Seconds

[Wilhelm Spickermann]

On 29-May-01 Marin David Condic wrote:
> Well, its actually a "requirement" that is spelled out in a standards
> document that is not (yet) accepted by the FCC (AFIK). WRT
> "event_start_time", the standard says: "A 32-bit unsigned integer quantity
> representing the start time of this alert event as the number of seconds
> since 00 hours UTC, January 6th, 1980 with the count of interleaving leap
> seconds included."
> 
> The situation is this: The source *may* be able to produce that time base &
> interleaving leap seconds. It would require a leap-second table that is
> periodically updated as new leap seconds happen - with the possibility that
> there is some delay between the leap-second and the table update. (In this
> app it isn't critical, but it might one day be critical in some other
> area...) The local time base is different and won't have access to any sort
> of leap-second update table. (Again, in this situation being off by a few
> seconds is not a big deal - but it might be in other parts of the
> application.) I can correct with a constant plus a "tuning" value sent from
> the source - if available - that represents leap seconds & hence we can be
> on the same time base. Hence a solution does exist.

I fail to see the problem here. "event_start_time" allows to operate a clock
which just counts _every_ second and to compute correct time differences
without using any tables or corrections from outside. Its only problems are
conversions to and from human readable form -- but if noone is there to install
new leap second tables, then noone will request such conversions there. All time
stamps used in communication with the outside world would be "event_start_time"
values. 

One pitfall remains: Someone asking for something to be done every day
precisely at noon. Then you will have to convince her or him that a
precisely _regular_ interval would be much better... :-))

Ada support is found in Ada.Real_Time. If I interpret the ARM correctly,
Real_Time counts each and every second and so it has to count added leap
seconds and it may not count omitted leap seconds. So it just has an offset to
the event_start_time and perhaps some (solvable) computational problems as
real_time spans have a small guaranteed range (1 hour) compared to real_time
stamps (50 years from program start-up).

Wilhelm

Re: Leap Seconds

[Marin David Condic]

event_start_time is an absolute time measurement from a known epoch. The
number of seconds since 1/6/80, 00:00:00 - *including leap seconds*. Failure
to count leap seconds internally means that when event_start_time says "Noon
Today" as a delta from the epoch, what you're really reading is "some number
of seconds since XXX". If *you* count leap seconds and *I* don't count leap
seconds and we agree to meet 1234567890 seconds from epoch XXX and *you* are
throwing in a few extra seconds, I'm going to be early. See the problem?

As I pointed out elsewhere, if you can do relative timing, it isn't an issue
unless you are spanning leap-seconds. Also, if your accuracy requirement
isn't that tight, then you can afford to have a discrepancy between the two.
In this case, I'm not in trouble, but I'd like to be thorough so that in
other areas that may use this time base, I've got the computations correct
in the event greater accuracy is needed.

Tucker Taft seems to indicate that there isn't anything in the standard or
the validation suite to check for leap second computations. I'm inclined to
believe him. Counting seconds in Ada.Real_Time has more to do with relative
time computations than with dates, etc. It seems unlikely that the standard
could require dealing with leap-seconds when there are very few systems (in
the overall scheme of things) that would have up-to-date information about
leap-seconds.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wilhelm Spickermann" <Wilhelm.Spickermann@t-online.de> wrote in message
news:mailman.991247484.29504.comp.lang.ada@ada.eu.org...
>
>
> I fail to see the problem here. "event_start_time" allows to operate a
clock
> which just counts _every_ second and to compute correct time differences
> without using any tables or corrections from outside. Its only problems
are
> conversions to and from human readable form -- but if noone is there to
install
> new leap second tables, then noone will request such conversions there.
All time
> stamps used in communication with the outside world would be
"event_start_time"
> values.
>
> One pitfall remains: Someone asking for something to be done every day
> precisely at noon. Then you will have to convince her or him that a
> precisely _regular_ interval would be much better... :-))
>
> Ada support is found in Ada.Real_Time. If I interpret the ARM correctly,
> Real_Time counts each and every second and so it has to count added leap
> seconds and it may not count omitted leap seconds. So it just has an
offset to
> the event_start_time and perhaps some (solvable) computational problems as
> real_time spans have a small guaranteed range (1 hour) compared to
real_time
> stamps (50 years from program start-up).
>
> Wilhelm
>

Re: Leap Seconds

[Larry Kilgallen]

In article <9f3fmc$o0f$1@nh.pace.co.uk>, "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> Tucker Taft seems to indicate that there isn't anything in the standard or
> the validation suite to check for leap second computations. I'm inclined to
> believe him. Counting seconds in Ada.Real_Time has more to do with relative
> time computations than with dates, etc. It seems unlikely that the standard
> could require dealing with leap-seconds when there are very few systems (in
> the overall scheme of things) that would have up-to-date information about
> leap-seconds.

It would be as bad as a computer system that attempts to predict
daylight savings time, which changes at the will of legislatures.

Re: Leap Seconds

[Joseph P Vlietstra]

I have a few recommendations/notes:

1. Subscribe to the leap second mailing list from USNO
   I don't have exact URL, since I receive leap second e-mail at work
and I subscribe
   to comp.lang.ada at home.  As you have noted, leap seconds are
painful to deal with.
   There is a proposal from the IAU Working Group on Reference Systems
(WGRS) to
   eliminate leap seconds from UTC.  If implemented, either UTC will be
redefined to
   be continuous (no leap seconds) or a new continuous time scale, UTS,
will be defined.
   Keep your fingers crossed.

2. Leap seconds are not introduced due to the Earth rotation SLOWING
down per se,
   they are more due to the fact that the Earth had already SLOWED down
slightly when
   the UTC time scale was defined.

3. If your system has exact time synchronization requirements, there is
probably a
   GPS receiver somewhere in the system.  If there is a GPS receiver,
you're in
   luck (sort of).  GPS provides a leap second correction factor to
compute UTC.
   It also provides information on future leap seconds on one of GPS
almanac pages.
   GPS seems to be the best mechanism of distributing the leap second announcement
   -- the Jan 1999 leap second was announce via GPS almost a day before
I received
   the official announcement from IERS (next note)

4. IERS Bulletin C (official leap second announcement)
   Issued at least 6 months before the leap second is introduced.
   In US, you can get it from http://maia.usno.navy.mil
   While you're at USNO, fetch the leap second file at
   ftp://maia.usno.navy.mil/ser7/tai-utc.dat
   We use this file in our leap second computations.

Re: Leap Seconds

[Wilhelm Spickermann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2442 bytes --]


On 30-May-01 Marin David Condic wrote:
> event_start_time is an absolute time measurement from a known epoch. The
> number of seconds since 1/6/80, 00:00:00 - *including leap seconds*. Failure
> to count leap seconds internally means that when event_start_time says "Noon
> Today" as a delta from the epoch, what you're really reading is "some number
> of seconds since XXX". If *you* count leap seconds and *I* don't count leap
> seconds and we agree to meet 1234567890 seconds from epoch XXX and *you* are
> throwing in a few extra seconds, I'm going to be early. See the problem?

Sorry, no  -- or at least at a different point. If we meet "1234567890 seconds
from epoch XXX" then no one will be early (if no one travels at too relativistic
speeds). The second is a well defined unit and there is no choice of
measurement. There is no leap second problem, if we use time differences to an
epoch. 
If we don�t want any leap second tables or regular updates for them, then
requiring that only "event_start_time" is used is just what we need to do that.

The leap second problem occurs if we use human oriented component times like
"5-dec-2011 14:23:22.5 UTC". Assume I could predict the time of the next earth
quake in San Francisco precisely to the millisecond (far future assumed). Then
I know when it will be -- but I don�t know how to tell it in component time
because of the future leap seconds decisions.
The leap second problem also occurs if someone uses varying length "units" like
"minute". If we start just a second before a leap second and add 3 seconds and
then one minute, we will not get the same result as if we add the minute first
and the seconds then.

BTW: In the good old days unixes used to have a clock which was a "time
difference to an epoch". But the POSIX time_t values we have now are _not_ "time
differences to an epoch" -- they are just a tightly packed form of a component
time with the funny property, that it would designate a time difference if
there wouldn�t have been any leap seconds.

...
> Tucker Taft seems to indicate that there isn't anything in the standard or
> the validation suite to check for leap second computations. I'm inclined to

If Ada.Calendar.Time_Of is called with a duration 86400.0 and then
converted back with Ada.Calendar.Split, we will get a duration of 0.0 (ARM
9.6(25)). So I think that Ada.Calendar cannot be used for computations if you
care for a second.

Wilhelm

Re: Leap Seconds

[Marin David Condic]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]

O.K. See my other post above - I phrased my original statement badly. You
are right that a measure of absolute seconds is going to remain constant. I
was thinking with respect to computing those seconds relative to dates. We
agree on a date/time to meet. You compute the seconds between now and then
and I compute the seconds between now and then and we both delay N seconds.
Your computation involves leap-seconds and mine doesn't. We've got a problem
in that one of us will be there early.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wilhelm Spickermann" <Wilhelm.Spickermann@t-online.de> wrote in message
news:mailman.991301489.12794.comp.lang.ada@ada.eu.org...
> Sorry, no  -- or at least at a different point. If we meet "1234567890
seconds
> from epoch XXX" then no one will be early (if no one travels at too
relativistic
> speeds). The second is a well defined unit and there is no choice of
> measurement. There is no leap second problem, if we use time differences
to an
> epoch.
> If we don�t want any leap second tables or regular updates for them, then
> requiring that only "event_start_time" is used is just what we need to do
that.
>
> The leap second problem occurs if we use human oriented component times
like
> "5-dec-2011 14:23:22.5 UTC". Assume I could predict the time of the next
earth
> quake in San Francisco precisely to the millisecond (far future assumed).
Then
> I know when it will be -- but I don�t know how to tell it in component
time
> because of the future leap seconds decisions.
> The leap second problem also occurs if someone uses varying length "units"
like
> "minute". If we start just a second before a leap second and add 3 seconds
and
> then one minute, we will not get the same result as if we add the minute
first
> and the seconds then.
>
> BTW: In the good old days unixes used to have a clock which was a "time
> difference to an epoch". But the POSIX time_t values we have now are _not_
"time
> differences to an epoch" -- they are just a tightly packed form of a
component
> time with the funny property, that it would designate a time difference if
> there wouldn�t have been any leap seconds.
>
> ...
> > Tucker Taft seems to indicate that there isn't anything in the standard
or
> > the validation suite to check for leap second computations. I'm inclined
to
>
> If Ada.Calendar.Time_Of is called with a duration 86400.0 and then
> converted back with Ada.Calendar.Split, we will get a duration of 0.0 (ARM
> 9.6(25)). So I think that Ada.Calendar cannot be used for computations if
you
> care for a second.
>
> Wilhelm
>

Re: Leap Seconds

[Wilhelm Spickermann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1619 bytes --]


On 31-May-01 Marin David Condic wrote:
> O.K. See my other post above - I phrased my original statement badly. You
> are right that a measure of absolute seconds is going to remain constant. I
> was thinking with respect to computing those seconds relative to dates. We
> agree on a date/time to meet. You compute the seconds between now and then
> and I compute the seconds between now and then and we both delay N seconds.

Hmm, none of us can compute the number of seconds before the IERS has
determined all the leap seconds in that time range. Once the leap seconds or
their absence are determined, we will get the same results.

> Your computation involves leap-seconds and mine doesn't. We've got a problem
> in that one of us will be there early.
> 
But a look on the next wall clock will show, who computed the wrong result (we
agreed upon a specific date and time). None of us will be early, if we interpret
the results of the computation correctly. 

The computation which includes leap seconds will compute the time difference and
the result can be used in a simple countdown clock or (hopefully) a delay
statement. The computation has to be postponed until the necessary information
is available.

The computation without leap seconds can be done at once but it doesn�t compute
a time difference. But the result can be compared to a POSIX clock, as this type
of "clock" jumps with every leap second inserted or omitted. The result is
unusable for delay statements. (I hope at least no one wants "delay 1.0;" to
mean "don�t wait" if its execution happens to fall on a negative leap second.)

Wilhelm

Re: Leap Seconds

[Marin David Condic]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2987 bytes --]

I don't know if you're getting all the posts to this thread, but I think if
you go back and re-read what I've said on the subject and what the original
problem is, you might have a better handle on what to address. Its already
been observed that you can't determine what the leap-seconds will be in the
future. The problem I had at hand was one where I don't have a network time
source or other sorts of data that would correct for leap-seconds. Your
comments are interesting but are not really addressing the problem. The
problem is one of computing seconds between two calendar dates (past or
future) and how to account for leap-seconds. If one has a clock available
that is correcting for leap-seconds, that's nice, but I don't. As far as I
can figure, there is no good answer to the problem except to know how many
leap-seconds actually occurred since their inception and there is no way to
know when they will occur in the future if your computations take you there.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wilhelm Spickermann" <Wilhelm.Spickermann@t-online.de> wrote in message
news:mailman.991382224.2673.comp.lang.ada@ada.eu.org...
>
> On 31-May-01 Marin David Condic wrote:
> > O.K. See my other post above - I phrased my original statement badly.
You
> > are right that a measure of absolute seconds is going to remain
constant. I
> > was thinking with respect to computing those seconds relative to dates.
We
> > agree on a date/time to meet. You compute the seconds between now and
then
> > and I compute the seconds between now and then and we both delay N
seconds.
>
> Hmm, none of us can compute the number of seconds before the IERS has
> determined all the leap seconds in that time range. Once the leap seconds
or
> their absence are determined, we will get the same results.
>
> > Your computation involves leap-seconds and mine doesn't. We've got a
problem
> > in that one of us will be there early.
> >
> But a look on the next wall clock will show, who computed the wrong result
(we
> agreed upon a specific date and time). None of us will be early, if we
interpret
> the results of the computation correctly.
>
> The computation which includes leap seconds will compute the time
difference and
> the result can be used in a simple countdown clock or (hopefully) a delay
> statement. The computation has to be postponed until the necessary
information
> is available.
>
> The computation without leap seconds can be done at once but it doesn�t
compute
> a time difference. But the result can be compared to a POSIX clock, as
this type
> of "clock" jumps with every leap second inserted or omitted. The result is
> unusable for delay statements. (I hope at least no one wants "delay 1.0;"
to
> mean "don�t wait" if its execution happens to fall on a negative leap
second.)
>
> Wilhelm
>

Re: Leap Seconds

[Wes Groleau]

> future) and how to account for leap-seconds. If one has a clock available
> that is correcting for leap-seconds, that's nice, but I don't. As far as I

With such a clear statement of the problem, the solution becomes obvious.
You need to either get such a clock or design an implementation that doesn't
need one.  Which is what many of the posts were trying to do for you, sort of.

:-)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Leap Seconds

[Marin David Condic]

Bzzzzzzzzzttt! Wrong Answer! :-) I can neither change the hardware I'm
programming nor can I change the specification of the data being sent to me.
Its always nice to simply define your problems away, but sometimes you
can't. I could pile another layer of abstraction on top of it and hope to
surround it with an SEP field, but there are less drastic measures possible.

In this case, I'm not going to sweat it too much. Being off by a few seconds
is not going to kill the system and I am leaving a method open for the
operator to remotely download "tuning constants" which will include an
offset to time. If they really need to get the accuracy up to match the
incoming message, they can send me the number of seconds to adjust by.

It was a rather interesting question WRT how Ada keeps time and its nice to
know what is (not) required concerning leap-seconds. Its obviously not a
problem for most apps, but where it matters, I now know what is likely going
on under the hood.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
news:3B17B3B8.B0626F22@ftw.rsc.raytheon.com...
> With such a clear statement of the problem, the solution becomes obvious.
> You need to either get such a clock or design an implementation that
doesn't
> need one.  Which is what many of the posts were trying to do for you, sort
of.
>

Re: Leap Seconds

[Wes Groleau]

> Bzzzzzzzzzttt! Wrong Answer! :-) I can neither change the hardware I'm
> programming nor can I change the specification of the data being sent to me.

In the first place, I was teasing, but in the second place ....

> Its always nice to simply define your problems away, ....
> .... I'm not going to sweat it too much. Being off by a few seconds
> is not going to kill the system and I am leaving a method open for the
> operator to remotely download "tuning constants" which will include an
> offset to time. If they really need to get the accuracy up to match the
> incoming message, they can send me the number of seconds to adjust by.

.... you just designed an implementation that doesn't need one.

Quod erat desideratum.   :-)

(I am not a Latin scholar, nor do I play one on the internet.)

> "Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
> news:3B17B3B8.B0626F22@ftw.rsc.raytheon.com...
> > With such a clear statement of the problem, the solution becomes obvious.
> > You need to either get such a clock or design an implementation that
> doesn't
> > need one.  Which is what many of the posts were trying to do for you, sort
> of.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Leap Seconds

[Marin David Condic]

> > offset to time. If they really need to get the accuracy up to match the
> > incoming message, they can send me the number of seconds to adjust by.
>
> .... you just designed an implementation that doesn't need one.
>
Thus demonstrating what a brilliant engineer and resourceful boy scout I am.


> Quod erat desideratum.   :-)
>
I think it is quod errat demonstratum - but I am not a professional Latin
scholar either - so I shouldn't be attempting this at home - without a net.
But I get your point.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Leap Seconds

[Wes Groleau]

> > Quod erat desideratum.   :-)
> >
> I think it is quod errat demonstratum - but I am not a professional Latin
> scholar either 

I don't know how many R's but yours is the mathematical QED -
"that which was to be proved" - I think.  Mine was (again,
I THINK) "that which was desired"

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Leap Seconds

[Marin David Condic]

Ahhhhhhh! O.K. I like that. In situations like this, I usually refer to "The
Book Of Devoutly To Be Desired Results", but Latin is good here too.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
news:3B1BB1E2.D629D821@ftw.rsc.raytheon.com...
> I don't know how many R's but yours is the mathematical QED -
> "that which was to be proved" - I think.  Mine was (again,
> I THINK) "that which was desired"
>

OT: Relativity misunderstood

[Wes Groleau]

> from epoch XXX" then no one will be early (if no one travels at too relativistic
> speeds).  .....

(To get a little off-topic)

The pop culture notion that you can leave earth
and return at near the speed of light, and find
your great-great-great-grandchildren older than
you is a misconception.

1. Special Relativity applies to two observers
   moving at an unchanging rate of speed relative
   to each other.  If you leave and return, your
   velocity must change.

2. IF you meet the conditions of special relativity,
   the theory predicts that EACH observer will see
   the OTHER'S clock as faster by the same amount.
   So if you somehow found a way to get back together
   in spite of the constant relative velocity condition,
   you would say, "Hey, your clock is several Megaseconds
   fast." and he/she would respond, "No, YOUR clock is 
   several Megaseconds fast."

Unfortunately, "pop culture" includes many sci-fi writers
and even several science NON-fiction writers, who keep
perpetuating this thing like an urban legend.

Even worse is the notion that black holes are the answer
to interstellar travel.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: OT: Relativity misunderstood

[Ted Dennison]

In article <3B167715.AA497455@ftw.rsc.raytheon.com>, Wes Groleau says...
>
>2. IF you meet the conditions of special relativity,
>   the theory predicts that EACH observer will see
>   the OTHER'S clock as faster by the same amount.
>   So if you somehow found a way to get back together
>   in spite of the constant relative velocity condition,
>   you would say, "Hey, your clock is several Megaseconds
>   fast." and he/she would respond, "No, YOUR clock is 
>   several Megaseconds fast."

The way I remember Carl Sagan explaining this on Cosomos way back when, this is
true only as long as you are still going at those different relative speeds.
Once one of you applies acceleration in some direction to make up the speed
difference, the "looks the same to each observer" aspect of relativity is off.
Thus when you are done accelerating (decelerating) so that you and the other
observer are at the same relative speed, you will indeed appear to have aged
very little compared to them.

That's the way I remember the explanation going, anway. (IANAP)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: OT: Relativity misunderstood

[Wes Groleau]

> The way I remember Carl Sagan explaining this on Cosomos way back when, this is
> true only as long as you are still going at those different relative speeds.
> Once one of you applies acceleration in some direction to make up the speed
> difference, the "looks the same to each observer" aspect of relativity is off.

I never watched Cosmos, but that was my point #1

> Thus when you are done accelerating (decelerating) so that you and the other
> observer are at the same relative speed, you will indeed appear to have aged
> very little compared to them.

And my point 2 was that the observation of time dilation is NOT a one-way
thing as the pop culture suggests.

Not that this has anything to do with leap seconds or Ada.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

RE: OT: Relativity misunderstood

[Wilhelm Spickermann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1829 bytes --]

(To connect to the topic again)

If I say that "some number of seconds after an epoch" is a well defined point
in time, then I�m definitely telling nonsense from the view of spacetime
physics. So I have to make the restriction that "good old theories" are
sufficiently applicable (no "pop culture" here :-)). These restrictions include
high speeds and different gravitation.

Wilhelm

On 31-May-01 Wes Groleau wrote:
>> from epoch XXX" then no one will be early (if no one travels at too
>> relativistic
>> speeds).  .....
> 
> (To get a little off-topic)
> 
> The pop culture notion that you can leave earth
> and return at near the speed of light, and find
> your great-great-great-grandchildren older than
> you is a misconception.
> 
> 1. Special Relativity applies to two observers
>    moving at an unchanging rate of speed relative
>    to each other.  If you leave and return, your
>    velocity must change.
> 
> 2. IF you meet the conditions of special relativity,
>    the theory predicts that EACH observer will see
>    the OTHER'S clock as faster by the same amount.
>    So if you somehow found a way to get back together
>    in spite of the constant relative velocity condition,
>    you would say, "Hey, your clock is several Megaseconds
>    fast." and he/she would respond, "No, YOUR clock is 
>    several Megaseconds fast."
> 
> Unfortunately, "pop culture" includes many sci-fi writers
> and even several science NON-fiction writers, who keep
> perpetuating this thing like an urban legend.
> 
> Even worse is the notion that black holes are the answer
> to interstellar travel.
> 
> -- 
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada

[OT] Black holes for interstellar travel (Re: OT: Relativity misunderstood)

[Jacob Sparre Andersen]

Wes:

> (To get a little off-topic)

[...]

> Even worse is the notion that black holes are the answer
> to interstellar travel.

If you don't mind travelling to a star in another universe - and
only one-way - black holes could be useful for interstellar
travel. Despite the general understanding of black holes, it
seems that the time you will be exposed to infinite forces
passing through a black hole is sufficiently short not to harm
you.

I have some difficulty accepting this, but Igor Novikov had some
very convincing arguments last time I heard him talk about this.

There are of course still the finite, but rather large forces
pulling you apart the rest of the time, but apparently Novikov
considers that a surmountable problem. ;-)

Jacob (who is a physicist, but not an astrophysicist)
-- 
Growing older is compulsory. Growing up isn't.

Re: [OT] Black holes for interstellar travel (Re: OT: Relativity misunderstood)

[Wes Groleau]

And the topic strays further.....

> > Even worse is the notion that black holes are the answer
> > to interstellar travel.

> If you don't mind travelling to a star in another universe - and
> only one-way - black holes could be useful for interstellar
> travel.  Despite the general understanding of black holes, it
> seems that the time you will be exposed to infinite forces
> passing through a black hole is sufficiently short not to harm
> you.

The notion that a black hole is a discontinuity making possible
an instantaneous transfer to another location is a hypothesis,
not a theory.  Has anyone ever volunteered to experimentally
test this hypothesis?  Has anyone figured out a way to transmit
the results of the experiment back to earth?

There are indeed scientists who have reasonable-sounding arguments
that a black hole may be such a discontinuity.  But anyone who
thinks such a discontinuity will make interstellar travel feasible
may be a paperback or magazine writer or TV star, but not a scientist.

Suppose we find that first volunteer.  If he should somehow live
long enough (yeah, cryogenic suspended animation--another "reasonable
idea" that is still a pipe dream or worse) to reach a black hole,
the project that sent him there will have been suspended and forgotten
by then.

What is the smallest known distance between any black hole and
any place humans MIGHT want to live at or travel to?  Second
smallest?  Add those distances together.  How long will the
one-way trip take, assuming the black hole part is instantaneous?

-- 
Wes Groleau, pessimist pro-tem
http://freepages.rootsweb.com/~wgroleau

Re: Leap Seconds

[Arthur Evans Jr]

In article <9f0ciq$itb$1@nh.pace.co.uk>, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote:

> While a handful of seconds over a number of years may not be a big deal in
> most cases, I could easily imagine where they might make a difference.
> (Especially when trying to sync up with something else that is using a time
> base somewhere in the past and wondering if it counts the leap seconds and
> you don't. Source A counts them, source B doesn't and you're in the middle
> trying to figure out 'does anybody really know what time it is?')

I expect that an Ada program that communicates with an unmanned
(unpersoned?) space ship might care very much indeed.  Suppose the
ship sends a message from somewhere near Saturn or some such, the
message including a time stamp.  You can tell how far away from
earth it is by the difference between that time stamp and the time
the message is received.  You might care a lot about a 1-second
error.  (I assume an adequately accurate clock on the vessal.)

Here the problem is not one Ada can solve.  You would need a clock
at the receiving station that either was never corrected for leap
seconds, or you would need a table of corrections.  To put it
differently, you need some sort of clock at the receiving station
that tells you how much time has elapsed since the vessal was
launched.  Given that, an Ada program is easy, providing you have a
big enough field to store all those seconds.

Art Evans

Re: Leap Seconds

[AG]

"Arthur Evans Jr" <ev_remove_this_ans@evans.pgh.pa.us> wrote in message
news:ev_remove_this_ans-2905012042430001@192.168.1.254...

> I expect that an Ada program that communicates with an unmanned
> (unpersoned?) space ship might care very much indeed.  Suppose the
> ship sends a message from somewhere near Saturn or some such, the
> message including a time stamp.
...
>
> Here the problem is not one Ada can solve.  You would need a clock
> at the receiving station that either was never corrected for leap
> seconds, or you would need a table of corrections.  To put it
> differently, you need some sort of clock at the receiving station
> that tells you how much time has elapsed since the vessal was
> launched.  Given that, an Ada program is easy, providing you have a
> big enough field to store all those seconds.

Well, considering we're talking about multi-year time spans and speeds
which, while still very low compared to the speed of light are not totally
negligible, does that mean that you need a clock which can account for
the relativity effects? Without any programming support? And what does
power that clock?
I would suggest that it should be the other way round - highly unlikely
any language could provide that sort of timer facility. Rather, it's the
language itself that should power the clock if it comes to such extreme
cases.

Re: Leap Seconds

[Larry Kilgallen]

In article <ev_remove_this_ans-2905012042430001@192.168.1.254>, ev_remove_this_ans@evans.pgh.pa.us (Arthur Evans Jr) writes:

> I expect that an Ada program that communicates with an unmanned
> (unpersoned?) space ship might care very much indeed.

   unstaffed

Re: Leap Seconds

[Wes Groleau]

> > I expect that an Ada program that communicates with an unmanned
> > (unpersoned?) space ship might care very much indeed.
> 
>    unstaffed

remote-controlled
uninhabited
empty
:-)


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Leap Seconds

[Marin David Condic]

As I said, I could easily imagine situations in which leap-seconds are going
to be a big deal. You don't even need to be going to Saturn for it to be a
problem. Much relative navigation depends on very accurate timekeeping and
the speed of light. (186000 miles/second - it's not just a good idea, its
the law! :-) For relative timekeeping, you can throw out leap seconds and be
done with it. However, its a problem for absolute timekeeping. If someone
outside your system is giving you a time that has leap-seconds included in
it, then you need to know how many or you can't really be in synch - except
in a relative sense. Just like not counting leap years, right?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Arthur Evans Jr" <ev_remove_this_ans@evans.pgh.pa.us> wrote in message
news:ev_remove_this_ans-2905012042430001@192.168.1.254...
> In article <9f0ciq$itb$1@nh.pace.co.uk>, "Marin David Condic"
> I expect that an Ada program that communicates with an unmanned
> (unpersoned?) space ship might care very much indeed.  Suppose the
> ship sends a message from somewhere near Saturn or some such, the
> message including a time stamp.  You can tell how far away from
> earth it is by the difference between that time stamp and the time
> the message is received.  You might care a lot about a 1-second
> error.  (I assume an adequately accurate clock on the vessal.)
>
> Here the problem is not one Ada can solve.  You would need a clock
> at the receiving station that either was never corrected for leap
> seconds, or you would need a table of corrections.  To put it
> differently, you need some sort of clock at the receiving station
> that tells you how much time has elapsed since the vessal was
> launched.  Given that, an Ada program is easy, providing you have a
> big enough field to store all those seconds.
>
> Art Evans

Re: Leap Seconds

[Larry Kilgallen]

In article <9f2ue6$hcm$1@nh.pace.co.uk>, "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> As I said, I could easily imagine situations in which leap-seconds are going
> to be a big deal. You don't even need to be going to Saturn for it to be a
> problem. Much relative navigation depends on very accurate timekeeping and
> the speed of light. (186000 miles/second - it's not just a good idea, its
> the law! :-) For relative timekeeping, you can throw out leap seconds and be
> done with it. However, its a problem for absolute timekeeping. If someone
> outside your system is giving you a time that has leap-seconds included in
> it, then you need to know how many or you can't really be in synch - except
> in a relative sense. Just like not counting leap years, right?

Leap years (adding a day) compensate for the revolution of the earth
around the sun, so we don't end up ((365/2)*(4/3)) years later with snow
on the 4th of July in New York City.

But I thought leap seconds compensated for the rotation of the earth,
rather than its revolution around the sun, since otherwise it would
eventually (12*60*60 leap seconds later) be very bright at midnight,
local time at the equator.

If I am going to Saturn I should not care about the rotation of the
earth until I return.

Re: Leap Seconds

[Marin David Condic]

I'm suspecting that if you add enough seconds to the clock, eventually,
those seconds become a day. The thing about leap-seconds is that they can be
positive or negative - probably going to your point about rotation about the
axis rather than around the sun. Since they started adding in leap-seconds,
they've always been positive.

In any case, my point was that your watch and my watch can both be ticking
off seconds in relative synch even though my watch says "4:30am, Tuesday"
{actually it doesn't "say" anything - you have to look at it.} and your
watch says "3:15pm, Wednesday" You can therefore safely ignore leap-seconds
and leap-years as long as all we're doing is saying "Let's meet for a beer
at Ruby Tuesdays in The Gardens Mall, Palm Beach Gardens, FL (free plug
there, guys!) in one hour, thirty two minutes and 15 seconds." As long as no
leap-seconds or leap-years happen between now and then, we're fine
(depending on traffic).

Its when you have to span over long stretches, that time and the calendar
get to be a problem. And let's please not even mention the Gregorian
calendar!

Time can be a *very* confusing business!

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

>
> Leap years (adding a day) compensate for the revolution of the earth
> around the sun, so we don't end up ((365/2)*(4/3)) years later with snow
> on the 4th of July in New York City.
>
> But I thought leap seconds compensated for the rotation of the earth,
> rather than its revolution around the sun, since otherwise it would
> eventually (12*60*60 leap seconds later) be very bright at midnight,
> local time at the equator.
>
> If I am going to Saturn I should not care about the rotation of the
> earth until I return.

Re: Leap Seconds

[Robert A Duff]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> In any case, my point was that your watch and my watch can both be ticking
> off seconds in relative synch even though my watch says "4:30am, Tuesday"
> {actually it doesn't "say" anything - you have to look at it.} and your
> watch says "3:15pm, Wednesday" You can therefore safely ignore leap-seconds
> and leap-years as long as all we're doing is saying "Let's meet for a beer
> at Ruby Tuesdays in The Gardens Mall, Palm Beach Gardens, FL (free plug
> there, guys!) in one hour, thirty two minutes and 15 seconds." As long as no
> leap-seconds or leap-years happen between now and then, we're fine
> (depending on traffic).

I don't get it.  If we both agree on when the epoch is, and we have a
way of counting seconds since the epoch, then we can agree to meet for
beer at 1,234,567,890.0 seconds after the epoch.  It doesn't matter that
my clock shows a different time than yours (because I count leap seconds
and you don't, or because I don't believe in "nightdark wasting time",
or because we're in different time zones, or whatever).

Isn't all the leap-seconds business about converting to/from a human
readable form.  I mean, leap seconds are exactly one-second long, just
like any other seconds.  (Unlike leap years, which are longer than other
years.)

By the way, it seems to me that Ada *forbids* counting leap seconds, in
that the upper bound of Day_Duration is 86_400.0, rather than 86_401.0.
True?

> Time can be a *very* confusing business!

Indeed.

- Bob

Re: Leap Seconds

[dale]

Robert A Duff wrote:

> By the way, it seems to me that Ada *forbids* counting leap seconds, in
> that the upper bound of Day_Duration is 86_400.0, rather than 86_401.0.
> True?


I doubt that it says that a time can't occur twice. You could get
around it simply by returning time = 86_400 for 2 seconds, no?

Dale

Re: Leap Seconds

[tmoran]

>beer at 1,234,567,890.0 seconds after the epoch.  It doesn't matter that
>my clock shows a different time than yours (because I count leap seconds
>and you don't,
  Absolutely.  If we agree, on January 1, 2003, to meet again in 365 days,
we will meet on January 1, 2004.  If we then agree to meet after another
365 days, we'll meet on December 31, 2004, not on January 1, 2005.  But if
we agree to meet on New Years Day, we'll meet in both cases on January 1.
If we agree to exchange radio signals after N seconds, no problem.  If we
agree to exchange them daily at midnight, it will make a difference whether
we are both modifying our clocks for leap seconds, or not.  Leap seconds
(or years) has nothing to do with the passage of time, only with the
naming of times.

Re: Leap Seconds

[Marin David Condic]

Yeah - once you're talking just seconds, that's fine because you are now in
relative time WRT some epoch. However, once you go to calendar time, you've
got a problem. Consider that we agree to meet on March 1. If you count leap
years and I don't, won't we have a difference in what the number of days is
between now and March 1? So if your epoch is 1/6/80-00:00:00 and my epoch is
1/1/96-00:00:00, how many seconds are between those to epochs? Won't it
matter if you count leap-seconds (leap-years?) or not? Naturally, being both
in the past, the conversion is a constant value. But what if I need to know
the seconds between either of those epochs and some date way in the future?
Unlike leap-years, leap-seconds are not predictable.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccsnhme0pd.fsf@world.std.com...
> I don't get it.  If we both agree on when the epoch is, and we have a
> way of counting seconds since the epoch, then we can agree to meet for
> beer at 1,234,567,890.0 seconds after the epoch.  It doesn't matter that
> my clock shows a different time than yours (because I count leap seconds
> and you don't, or because I don't believe in "nightdark wasting time",
> or because we're in different time zones, or whatever).

Re: Leap Seconds

[Paul Storm]

Marin David Condic wrote:
> 
> Yeah - once you're talking just seconds, that's fine because you are now in
> relative time WRT some epoch. However, once you go to calendar time, you've
> got a problem. Consider that we agree to meet on March 1. If you count leap
> years and I don't, won't we have a difference in what the number of days is
> between now and March 1? So if your epoch is 1/6/80-00:00:00 and my epoch is
> 1/1/96-00:00:00, how many seconds are between those to epochs? Won't it
> matter if you count leap-seconds (leap-years?) or not? Naturally, being both
> in the past, the conversion is a constant value. But what if I need to know
> the seconds between either of those epochs and some date way in the future?
> Unlike leap-years, leap-seconds are not predictable.
> 
This is not precise.  Leap seconds are well defined.  You CAN calculate
a leap second for any specific future time.

It is theoretically possible that there may never be any more leap
seconds promulgated. (not likely, I'll admit)  In which case the current
list of established leap seconds are known.

At any given run time of the program the leap seconds are(or will be)
defined and established.  Hence you can calculate for any future times
in systems applicable to leap seconds. Furthermore you can determine
what leap seconds were applicable for any (previous) execution of the
program.  Designing your application to look up the leap second
constants at run time is certainly possible.
The rest is commentary on how to code it.

Regards.

Re: Leap Seconds

[Joseph P Vlietstra]

Paul Storm wrote:
> This is not precise.  Leap seconds are well defined.  You CAN calculate
> a leap second for any specific future time.

While it's possible to compute UTC - UT1 for any specific future time
you can't use this knowledge to predict when leap seconds will occur.
BIPM reserves the right to introduce leap seconds and BIPM doesn't quite
follow the leap second algorithm specified in the definition of UTC:
-- BIPM seems to have a self-imposed constraint of introducing a leap
   second on a 6 month boundary rather than a 3 month boundary
-- BIPM has been keeping UTC - UT1 smaller than the allowable 0.9 s

You can't use past BIPM behavior to predict future behavior.
BIPM will probably avoid introducing a leap second until after the 2003
IAU meeting (when the resolution to eliminate leap seconds is up for
a vote).

> It is theoretically possible that there may never be any more leap
> seconds promulgated. (not likely, I'll admit)

Actually, it's about 50% likely that no more leap seconds will be
introduced.  Not because of Earth rotation or other technical reason,
the IAU may simply vote it out of existence.

BTW: Leap seconds are improvement over the previous scheme
     (Frequent 0.1 s adjustments)
							Joe Vl

Re: Leap Seconds

[Wes Groleau]

> problem. Much relative navigation depends on very accurate timekeeping and
> the speed of light. (186000 miles/second - it's not just a good idea, its

In that case, let's make it 186,324.xx  or somthing like that.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Leap Seconds

[Marin David Condic]

Well, if one wishes to be a stickler for accuracy, I suppose yours is a
better interpretation of the law.

But there is a Murphy's Law derivative that states that all engineering
values will invariably be expressed in the least usable units. Thus, we
*really* need to express this number in Furlongs per Fortnight. (and start
*that* whole discussion all over again... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
news:3B1672F7.2298EF6@ftw.rsc.raytheon.com...
>
> > problem. Much relative navigation depends on very accurate timekeeping
and
> > the speed of light. (186000 miles/second - it's not just a good idea,
its
>
> In that case, let's make it 186,324.xx  or somthing like that.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: Leap Seconds

[Darren New]

Arthur Evans Jr wrote:
> I expect that an Ada program that communicates with an unmanned
> (unpersoned?) space ship might care very much indeed.

Not really. Firstly, I'd be surprised if an uncompensated clock on an
unprotected spaceship actually stayed accurate to a half-second over the
lifetime of its mission. I could be wrong, there.

Leap seconds are really only a problem when calculating intervals
between two declared dates. If you want to know the number of seconds
since some epoch, leap seconds might make a difference. If you want to
know when it's some number of seconds since you launched the spaceship,
the spaceship doesn't need to know about leap seconds, and neither does
ground control if they don't adjust their own clock for leap seconds.

Leap seconds are there to make midnight be "the same time" every day
just like leap days are there to make Jan 1 be the same time every year. 

> Here the problem is not one Ada can solve.  You would need a clock
> at the receiving station that either was never corrected for leap
> seconds, or you would need a table of corrections.

Given clock drift, I don't imagine either of these would be adiquate.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
       San Diego, CA, USA (PST).  Cryptokeys on demand.
     This is top-quality raw fish, the Rolls-Rice of Sushi!