Leap Seconds 
Author Message
 Leap Seconds

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

Web:       http://www.*-*-*.com/



Tue, 11 Nov 2003 22:17:51 GMT  
 Leap Seconds

Quote:

> 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.

Quote:

> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution

> Web:      http://www.mcondic.com/

--

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)


Wed, 12 Nov 2003 06:02:35 GMT  
 Leap Seconds
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

Web:      http://www.mcondic.com/


Quote:

> 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.



Sat, 15 Nov 2003 22:43:36 GMT  
 Leap Seconds

Quote:

>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



Sun, 16 Nov 2003 00:02:33 GMT  
 Leap Seconds
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

Web:      http://www.mcondic.com/


Quote:

> >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




Sun, 16 Nov 2003 00:46:32 GMT  
 Leap Seconds
Quote:
> 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."


Sun, 16 Nov 2003 02:38:25 GMT  
 Leap Seconds
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

Web:      http://www.mcondic.com/


Quote:
> > 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."



Sun, 16 Nov 2003 03:26:06 GMT  
 Leap Seconds

Quote:

> 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



Sun, 16 Nov 2003 08:42:27 GMT  
 Leap Seconds



Quote:
> 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.


Sun, 16 Nov 2003 18:14:12 GMT  
 Leap Seconds

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

   unstaffed


Sun, 16 Nov 2003 19:20:21 GMT  
 Leap Seconds
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

Web:      http://www.mcondic.com/



Quote:

> 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



Sun, 16 Nov 2003 22:00:36 GMT  
 Leap Seconds

Quote:
> 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.



Sun, 16 Nov 2003 23:33:18 GMT  
 Leap Seconds
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

Web:      http://www.mcondic.com/

Quote:

> 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.



Sun, 16 Nov 2003 23:39:29 GMT  
 Leap Seconds

Quote:

> 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.

Quote:
> 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!



Mon, 17 Nov 2003 00:36:46 GMT  
 Leap Seconds


Quote:
> 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



Mon, 17 Nov 2003 02:20:24 GMT  
 
 [ 48 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. Calendar - leap seconds

2. STD: Leap Seconds and COBOL

3. Leap Seconds

4. Leap seconds (was Ref.: Re: Ref.: Re: Ref.: Re: Time.local bug? )

5. Ada as a Second Language (second edition)

6. Second CFP: Workshop on Deductive Databases at JICSLP'92 Second Call for Participation

7. Testing for leap year

8. leap years, julian date, and stuff.

9. leap year

10. Clipper Code for Leap Year

11. S87 Leap Year Problem

 

 
Powered by phpBB® Forum Software