Calendar - leap seconds

Calendar - leap seconds

[singlespeeder]

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;


Am I best just declaring my own subtype with the required range?

singlespeeder

RE: Calendar - leap seconds

[Wilhelm Spickermann]

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


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;
> 
> 
> Am I best just declaring my own subtype with the required range?

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 don�t have the IEEE 1003.1 standard, but
I�ve heard, that they even gave an arithmetic expression for computing
a time_t value from a broken time (without using a leap second list).
Do our library implementations depend on this? My first impression for
GNAT is that they do. So I cannot switch my Operating System (Linux)
from using /usr/share/zoneinfo/posix/Europe/Berlin (no leap seconds)
to /usr/share/zoneinfo/right/Europe/Berlin (with leap seconds) without
breaking Ada. :-(

Wilhelm

Re: Calendar - leap seconds

[Nick Roberts]

I'm going to upset people here :-/ but Ada.Calendar should never have dealt
with the extremely thorny issue of converting continuous absolute time to
and from a calendrical system such as Gregorian (or whatever you want to
call it). It should have been called Ada.Time_Functions and simply had two
functions such as To_MJD(:Time) and To_Time(:MJD).*

There could then have been an optional package
Ada.Text_IO.Gregorian_Calendar, as well as perhaps
Ada.Text_IO.Time_Within_Day (for hours minutes and seconds), etc.

Ah well. That's with the benefit of hindsight, I suppose.

--
Nick Roberts
http://www.AdaOS.org


* MJD: the Modified Julian Date system, offset but otherwise identical to
the system astronomers use to reckon absolute time on a simple continuous
scale. The unit is SI seconds.

Re: Calendar - leap seconds

[Robert A Duff]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> I'm going to upset people here :-/ but Ada.Calendar should never have dealt
> with the extremely thorny issue of converting continuous absolute time to
> and from a calendrical system such as Gregorian (or whatever you want to
> call it). It should have been called Ada.Time_Functions and simply had two
> functions such as To_MJD(:Time) and To_Time(:MJD).*
> 
> There could then have been an optional package
> Ada.Text_IO.Gregorian_Calendar, as well as perhaps
> Ada.Text_IO.Time_Within_Day (for hours minutes and seconds), etc.

I'm not sure why moving some of the functionality to a
Gregorian_Calendar package would "upset" anyone.
It seems like a fairly minor change.

I do think it's a mistake to have the Clock function in the same package
as all those conversion functions.  Clock is doing I/O, and shouldn't be
mixed with the rest (the rest being "pure" code).

I see the same mistake in Text_IO -- it mixes formatting with I/O.

I find it annoying, for example, that if I want decimal-formatted
integer, I can use 'Image, but if I want hexdecimal, I have to import
Text_IO (or write my own).  Hexadecimal formatting has nothing directly
to do with I/O of character strings!

- Bob

Re: Calendar - leap seconds

[Laurent Guerby]

Robert A Duff <bobduff@world.std.com> writes:
> [...] I find it annoying, for example, that if I want decimal-formatted
> integer, I can use 'Image, but if I want hexdecimal, I have to import
> Text_IO (or write my own).  Hexadecimal formatting has nothing directly
> to do with I/O of character strings!

This could be fixed by having separate packages offering all non
IO/time services, and just renaming declarations inside the IO/time
packages. The last point (renaming) is just implementation, it could
be just left out of the standard and be put as a RM note, this is to
say it shouldn't put a significant burden on implementors (move code
and put a few renames) and should be 100% upward compatible for users.

-- 
Laurent Guerby <guerby@acm.org>

Re: Calendar - leap seconds

[Nick Roberts]

"Laurent Guerby" <guerby@acm.org> wrote in message
news:863dc9cyfj.fsf@acm.org...
> Robert A Duff <bobduff@world.std.com> writes:
> > [...] I find it annoying, for example, that if I want decimal-formatted
> > integer, I can use 'Image, but if I want hexdecimal, I have to import
> > Text_IO (or write my own).  Hexadecimal formatting has nothing directly
> > to do with I/O of character strings!
>
> This could be fixed by having separate packages offering all non
> IO/time services, and just renaming declarations inside the IO/time
> packages. The last point (renaming) is just implementation, it could
> be just left out of the standard and be put as a RM note, this is to
> say it shouldn't put a significant burden on implementors (move code
> and put a few renames) and should be 100% upward compatible for users.

Not exactly. It would not fix the fact that Ada.Calendar and Ada.Text_IO
cannot be pure.

On the other hand, it would be a nice fix to introduce two new standard,
declared pure, packages Ada.Calendar_Conversions (with everything in
Ada.Calendar except Clock, and perhaps more) and Ada.Text_Formatting (with
everything in Ada.Text_IO except actual I/O operations). Implementations
would then (almost) inevitably complete the corresponding declarations in
Ada.Calendar and Ada.Text_IO by body renamings.

--
Nick Roberts
http://www.AdaOS.org

Re: Calendar - leap seconds

[Laurent Guerby]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> "Laurent Guerby" <guerby@acm.org> wrote in message
> > This could be fixed by having separate packages offering all non
> > IO/time services, and just renaming declarations inside the IO/time
> > packages. The last point (renaming) is just implementation, it could
> > be just left out of the standard and be put as a RM note, this is to
> > say it shouldn't put a significant burden on implementors (move code
> > and put a few renames) and should be 100% upward compatible for users.
> 
> Not exactly. It would not fix the fact that Ada.Calendar and Ada.Text_IO
> cannot be pure.
> 
> On the other hand, it would be a nice fix to introduce two new standard,
> declared pure, packages Ada.Calendar_Conversions (with everything in
> Ada.Calendar except Clock, and perhaps more) and Ada.Text_Formatting (with
> everything in Ada.Text_IO except actual I/O operations). Implementations
> would then (almost) inevitably complete the corresponding declarations in
> Ada.Calendar and Ada.Text_IO by body renamings.

I think we're saying the same thing here.  Ada.Calendar and
Ada.Text_IO cannot be pure for sure, but the new packages (I called
them "separate package", you gave them explicit names) can be.

-- 
Laurent Guerby <guerby@acm.org>

Re: Calendar - leap seconds

[Joseph P Vlietstra]

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.

Re: Calendar - leap seconds

[Wilhelm Spickermann]

On 20-Mar-01 Joseph P Vlietstra wrote:
...
> 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.
...
> 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.

Thank You very much!

I hope the leap second insertion will be suspended for some decades.
It should be possible then, to give an algorithm for leap second
insertion for the next few hundred years...  (But this will not remove
the damage that has been done by creating a second definition of the
timestamps given as time_t or struct timeval.)

Wilhelm

Re: Calendar - leap seconds

[Kent Paul Dolan]

Florian Weimer <fw@deneb.enyo.de> wrote:

> Are there other pragmas with a similarly scoped effect?

And into my head full blown lept lust for a programming language
whose source code syntax was SGML based, like HTML or VML:

<pragma pname = "foo" pparm_the_first = "bar"> 

 <!-- lots of code -->

 <namespace nsname = "baz">

   <!-- lots more code -->

 </namespace nsname = "baz">

</pragma pname = "foo"> 

which style would let comments be bound to the code they comment,
provide easy support for pretty printing, and perhaps some other
benefits that didn't enjoy that leap with the original idea.

Now command line options would instead become style sheets!

You have to be a power typist, and more than a bit mad, to love this
kind of cruft, of course.

The last line could be just:

</pragma>

but including the pname value allows better checking for matching scope
delimiters.


Just day-dreaming.


Cheers!

xanthian.
--
Kent Paul Dolan <xanthian@well.com>

-- 
Posted from smtp.well.com [208.178.101.27] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Calendar - leap seconds

[Simon Wright]

xanthian@well.com (Kent Paul Dolan) writes:

> And into my head full blown lept lust for a programming language
> whose source code syntax was SGML based, like HTML or VML:
> 
> <pragma pname = "foo" pparm_the_first = "bar"> 
> 
>  <!-- lots of code -->
> 
>  <namespace nsname = "baz">
> 
>    <!-- lots more code -->
> 
>  </namespace nsname = "baz">
> 
> </pragma pname = "foo"> 

Have you come across XSLT? A tiny fragment from my not-formally-announced
code framework generator at http://www.pushface.org/coldframe/ ..

  <!-- Generate the individual components of the class identifier 
       or instance record. -->
  <xsl:template match="attribute" mode="instance-record-component">
    <xsl:text>    </xsl:text>
    <xsl:call-template name="attribute-name"/>
    <xsl:text> : </xsl:text>
    <xsl:call-template name="attribute-type"/>
    <xsl:if test="initial">
      <xsl:text> := </xsl:text>
      <xsl:value-of select="initial"/>
    </xsl:if>
    <xsl:text>;&#10;</xsl:text>
  </xsl:template>

Templates are slightly like subprograms; the outer one is a matcher,
which finds all the <attribute> nodes in (the current subset of) the
input document (but only operates in the "instance-record-component"
mode), while the target of <xsl:call-template name="attribute-type"/>
is only invoked when explicitly named .. <xsl:if test="initial">
succeeds if the current <attribute> element contains an <initial>
element .. <xsl:value-of select="initial"/> outputs the content of
said <initial> element .. loads more fun available!

> The last line could be just:
> 
> </pragma>

I rather think this is required in SGML? not sure ..