Calling C time function from ADA-95

Calling C time function from ADA-95

[Faust!]

Looking for a way to call out to time.h for system clock information
from Ada-95.....

Anyhave know of or have code that might help?  If not, how about 
general idea of how to implement....Thanks

please cc: faust@primary.net

Re: Calling C time function from ADA-95

[Matthew Heaney]

noyb@here.net (Faust!) writes:

> Looking for a way to call out to time.h for system clock information
> from Ada-95.....
> 
> Anyhave know of or have code that might help?  If not, how about 
> general idea of how to implement....Thanks


What's wrong with package Calendar or Real_Time?

Re: Calling C time function from ADA-95

[Charles Hixson]

Matthew Heaney wrote:
> 
> noyb@here.net (Faust!) writes:
> 
> > Looking for a way to call out to time.h for system clock information
> > from Ada-95.....
> >
> > Anyhave know of or have code that might help?  If not, how about
> > general idea of how to implement....Thanks
> 
> What's wrong with package Calendar or Real_Time?
Well, since you asked, the year type of Calendar has a **much** too
restricted range.  Saving space by restricting the size of the year that
way reminds me of all of the programs that stored only two digits for
their year in the '60s, and now their descendants are delighting
everyone.

To be fair, the Ada year type would throw an exception, but that merely
means that it warns me that it is unusable.

-- 
Charles Hixson	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us

Re: Calling C time function from ADA-95

[Dale Stanbrough]

Charles Hixson  writes:

"Well, since you asked, the year type of Calendar has a **much** too
 restricted range.  Saving space by restricting the size of the year that
 way reminds me of all of the programs that stored only two digits for
 their year in the '60s, and now their descendants are delighting
 everyone."


I always thought the range was chosen to allow for fast leap year 
calculations (year mod 4, excluding the more expensive mod 100/mod 400)
rather than to save space. Does anyone have any better knowledge?

Dale

Re: Calling C time function from ADA-95

[Larry Kilgallen]

In article <6lhnan$1vi$1@goanna.cs.rmit.edu.au>, Dale Stanbrough <dale@goanna.cs.rmit.edu.au> writes:
> Charles Hixson  writes:
> 
> "Well, since you asked, the year type of Calendar has a **much** too
>  restricted range.  Saving space by restricting the size of the year that
>  way reminds me of all of the programs that stored only two digits for
>  their year in the '60s, and now their descendants are delighting
>  everyone."
> 
> 
> I always thought the range was chosen to allow for fast leap year 
> calculations (year mod 4, excluding the more expensive mod 100/mod 400)
> rather than to save space. Does anyone have any better knowledge?

I inferred from discussion in comp.lang.ada that there was a goal
of avoiding support for periods of time where popes and kings were
changing the calendar.  Someone said that those with more longterm
needs should write their own calendar package.  There is a lot of
politics in deciding how dates work once you escape the period
covered by the current algorithm.

Larry Kilgallen

Re: Calling C time function from ADA-95

[Markus Kuhn]

Dale Stanbrough wrote:
> 
> Charles Hixson  writes:
> 
> "Well, since you asked, the year type of Calendar has a **much** too
>  restricted range.  Saving space by restricting the size of the year that
>  way reminds me of all of the programs that stored only two digits for
>  their year in the '60s, and now their descendants are delighting
>  everyone."
> 
> I always thought the range was chosen to allow for fast leap year
> calculations (year mod 4, excluding the more expensive mod 100/mod 400)
> rather than to save space. Does anyone have any better knowledge?

Many existing systems (most likely your Unix workstation as well!) do
not handle leap years correctly outside the 1901..2099 range. The
Ada95 standard just documents a restriction that is not imposed
by the Ada standard, but by many commonly used operating systems.

It is foolish to access the C API directly for this reason because
(although this is rarely documented), it also has only a valid year
range until 2099:

For instance POSIX.1 (ISO/IEC 9945-1:1996) defines its time scale as
follows

      2.2.2.113  seconds since the Epoch: A value to be interpreted
      as the number of seconds between a specified time and the
      Epoch. 

      A Coordinated Universal Time name (specified in terms of
      seconds (tm_sec), minutes (tm_min), hours (tm_hour), days
      since January 1 of the year (tm_yday), and calendar year minus
      1990 (tm_year) is related to a time represented as seconds
      since the Epoch, according to the expression below. 

      If the year < 1970 or the value is negative, the relationship is
      undefined. If the year >= 1970 and the value is nonnegative, the
      value is related to a Coordinated Universal time name
      according to the expression: 

            tm_sec + tm_min*60 + tm_hour*3600 +
            tm_yday*86_400 + (tm_year-70)*31_536_000 +
            ((tm_year-69)/4*86_400 

There will be a 86400 s log gap between 2100-02-28 24:00:00Z and
2100-03-01 00:00:00Z (same for the years 2200, 2300, 2500, ...),
because the leap year rule used in the above formula is only valid in
the year interval 1901..2099. This is not of concern when the seconds
since the Epoch are counted in 32-bit signed integer variables, which
will overflow on 2038-01-19 03:14:08Z, but on 64-bit machines, this
should be fixed, since the Y2K problem has tought us that it is
conceivable that software will be in use for centuries and it is
ulikely that mankind will agree on a new calendar scheme any time soon
given the enourmous problems that even a century roll-over causes in
our IT infrastructure. 

The correct formula (I think :) would be:

            tm_sec + tm_min * 60 + tm_hour * 3600 +
            tm_yday * 86_400 + (tm_year-70) * 31_536_000 +
            ((tm_year-69)/4 - (tm_year-1)/100 +
            (tm_year+299)/400) * 86_400 

If this were widely implemented and time_t were a 64-bit signed
integer on POSIX systems, then the year range could be extended to
the year 9999.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Calling C time function from ADA-95

[Charles Hixson]

That may be so.  But my interest in small pieces of time declines as
their distance from me increases.  Thus, I doubt that I will ever be
interested in which hour Cleopatra met Marc Antony.  The season might be
of interest, or the year, but hardly more than that.
When issuing cards to people, I want to represent their birthdate, even
if it happened before 1900 (a declining number, I admit).  I'm not
interested in the second that they were born, or even the minute (or,
for that matter, the hour..but I think that the hour should be kept).  .

I think that times should be kept on a kind of sliding scale.  Say
seconds for the current decade, minutes for the current century, hours
for the current 100 centuries.  Days for the current 10,000 centuries.
Etc.  That should be sufficient overkill for ANYONE that would be
satisfied by the current date structure anyway. And for the for any time
within the last/next day or two milliseconds could be specified. 
Basically this is intended as a computationally cheaper (right? wrong?)
substitute for the log of the number of time units away from NOW

Astrophysicists and Quantum Mechanics, of course, would still need their
own special date structures, but they couldn't use the standard scale
anyway.

Markus Kuhn wrote:
> 
> Dale Stanbrough wrote:
> >
> > Charles Hixson  writes:
> >
> > "Well, since you asked, the year type of Calendar has a **much** too
> >  restricted range.  Saving space by restricting the size of the year that
> >  way reminds me of all of the programs that stored only two digits for
> >  their year in the '60s, and now their descendants are delighting
> >  everyone."
> >
> > I always thought the range was chosen to allow for fast leap year
> > calculations (year mod 4, excluding the more expensive mod 100/mod 400)
> > rather than to save space. Does anyone have any better knowledge?
> 
> Many existing systems (most likely your Unix workstation as well!) do
> not handle leap years correctly outside the 1901..2099 range. The
> Ada95 standard just documents a restriction that is not imposed
> by the Ada standard, but by many commonly used operating systems.
> 
> It is foolish to access the C API directly for this reason because
> (although this is rarely documented), it also has only a valid year
> range until 2099:
> 
> For instance POSIX.1 (ISO/IEC 9945-1:1996) defines its time scale as
> follows
> 
>       2.2.2.113  seconds since the Epoch: A value to be interpreted
>       as the number of seconds between a specified time and the
>       Epoch.
> 
>       A Coordinated Universal Time name (specified in terms of
>       seconds (tm_sec), minutes (tm_min), hours (tm_hour), days
>       since January 1 of the year (tm_yday), and calendar year minus
>       1990 (tm_year) is related to a time represented as seconds
>       since the Epoch, according to the expression below.
> 
>       If the year < 1970 or the value is negative, the relationship is
>       undefined. If the year >= 1970 and the value is nonnegative, the
>       value is related to a Coordinated Universal time name
>       according to the expression:
> 
>             tm_sec + tm_min*60 + tm_hour*3600 +
>             tm_yday*86_400 + (tm_year-70)*31_536_000 +
>             ((tm_year-69)/4*86_400
> 
> There will be a 86400 s log gap between 2100-02-28 24:00:00Z and
> 2100-03-01 00:00:00Z (same for the years 2200, 2300, 2500, ...),
> because the leap year rule used in the above formula is only valid in
> the year interval 1901..2099. This is not of concern when the seconds
> since the Epoch are counted in 32-bit signed integer variables, which
> will overflow on 2038-01-19 03:14:08Z, but on 64-bit machines, this
> should be fixed, since the Y2K problem has tought us that it is
> conceivable that software will be in use for centuries and it is
> ulikely that mankind will agree on a new calendar scheme any time soon
> given the enourmous problems that even a century roll-over causes in
> our IT infrastructure.
> 
> The correct formula (I think :) would be:
> 
>             tm_sec + tm_min * 60 + tm_hour * 3600 +
>             tm_yday * 86_400 + (tm_year-70) * 31_536_000 +
>             ((tm_year-69)/4 - (tm_year-1)/100 +
>             (tm_year+299)/400) * 86_400
> 
> If this were widely implemented and time_t were a 64-bit signed
> integer on POSIX systems, then the year range could be extended to
> the year 9999.
> 
> Markus
> 
> --
> Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
> email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

-- 
Charles Hixson	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us

Re: Calling C time function from ADA-95

[Markus Kuhn]

Charles Hixson wrote:
> I think that times should be kept on a kind of sliding scale.  Say
> seconds for the current decade, minutes for the current century, hours
> for the current 100 centuries.  Days for the current 10,000 centuries.
> Etc.

That sounds like a revolutionary new concept, but somehow I remember
having heard one of our Computer Science professors telling us already
about such advanced mechanisms for representing scalar values.
Isn't this stuff called "floating point numbers" or so?  :-)

> That should be sufficient overkill for ANYONE that would be
> satisfied by the current date structure anyway.

Just use a 64-bit integer counter for the seconds since some epoch,
which will last for the next 290 billion years (and goes backwards
far beyond the big bang). Add a 32-bit counter with the number
of nanoseconds since the last second started, and you get a
resolution that is an order of magnitude better than your CPU
frequency and the accuracy of good atomic clocks. The 32-bit
nanosecond counter has the nice property that inserted
leap seconds in your time scale (say UTC) can be represented
nicely as values 10**9..2*10**9-1.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Calling C time function from ADA-95

[Charles Hixson]

Sure, it could easily be based on floating point numbers.  And yes, I
can write my own calendar package.  Everybody seems to end up needing to
write their own calendar.  But doesn't that sort of defeat the purpose
of a system library?  Everyone could write their own sine_table package,
too, but the system routine, being good enough, almost nobody does.  If
people are needing to re-implement the calendar, then that's a sign that
the calendar package ... well, broken usually means something else.

Markus Kuhn wrote:
> 
> Charles Hixson wrote:
> > I think that times should be kept on a kind of sliding scale.  Say
> > seconds for the current decade, minutes for the current century, hours
> > for the current 100 centuries.  Days for the current 10,000 centuries.
> > Etc.
> 
> That sounds like a revolutionary new concept, but somehow I remember
> having heard one of our Computer Science professors telling us already
> about such advanced mechanisms for representing scalar values.
> Isn't this stuff called "floating point numbers" or so?  :-)
> 
> > That should be sufficient overkill for ANYONE that would be
> > satisfied by the current date structure anyway.
> 
> Just use a 64-bit integer counter for the seconds since some epoch,
> which will last for the next 290 billion years (and goes backwards
> far beyond the big bang). Add a 32-bit counter with the number
> of nanoseconds since the last second started, and you get a
> resolution that is an order of magnitude better than your CPU
> frequency and the accuracy of good atomic clocks. The 32-bit
> nanosecond counter has the nice property that inserted
> leap seconds in your time scale (say UTC) can be represented
> nicely as values 10**9..2*10**9-1.
> 
> Markus
> 
> --
> Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
> email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

-- 
Charles Hixson	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us

Re: Calling C time function from ADA-95

[Larry Kilgallen]

In article <357DA2E1.704E9A16@earthling.net>, Charles Hixson <charleshixson@earthling.net> writes:
> Sure, it could easily be based on floating point numbers.  And yes, I
> can write my own calendar package.  Everybody seems to end up needing to
> write their own calendar.  But doesn't that sort of defeat the purpose
> of a system library?  Everyone could write their own sine_table package,
> too, but the system routine, being good enough, almost nobody does.  If
> people are needing to re-implement the calendar, then that's a sign that
> the calendar package ... well, broken usually means something else.

But computers should model the real world, and governments have diverged
in their definitions of the calendar.  If you write a package it will work
back to the year 1000 for everyone who agrees with your choice of which
government standards to use during which periods.  I might choose another.

Of course, like the folks who don't care about leap-seconds, you will
gather a larger constituency if you convince people that 12 days of
divergence does not matter in the greater scheme of things.

For those who really care about dates 300 years ago, however, it does
matter which calendar system is to be honored.  If you want to assume
that the current algorithm just goes back into the past in a regular
pattern, you will satisfy those who want a neat mathematical answer,
but not the needs of those who actually care about the dates in question.

Larry Kilgallen

Re: Calling C time function from ADA-95

[Markus Kuhn]

Faust! wrote:
> Looking for a way to call out to time.h for system clock information
> from Ada-95.....

For easy POSIX and C API access, you should install a POSIX.5 binding.
A freely available one is FLORIST on

  http://www.cs.fsu.edu/~baker/florist.html

Without such a binding, portable access to C/POSIX libs is rather messy
in Ada, because Ada doesn't allow you to access the preprocessor
constants in *.h files and you have to copy them manually or write
an install skript that transforms .h files into .ads files. Bindings
such as FLORIST have all these constants converted for you into
Ada constants and you can then use them in a portable way. In
addition, reading the FLORIST source code is a good way of learning
how to write mixed Ada/C programms. Have a look at it.

I don't use Florist at the moment, because it does not run
on new Linux systems with glibc2 (e.g., Red Hat 5.0). What I
do is to cut and paste from Florist my own POSIX binding together
with only the functionality that I need in my application.
This works very nicely, and since I use the same API, I can
easily throw away my own binding and replace it by the full
Florist package once it runs on Red Hat 5. Even if Florist does
not yet run on your OS, the posix.ads and posix-c.ads files
that it installs are *very* valuable sources of cut-and-paste
material for your own quick-n-dirty bindings.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>