* Calling C time function from ADA-95 @ 1998-06-07 0:00 Faust! 1998-06-06 0:00 ` Matthew Heaney 1998-06-07 0:00 ` Markus Kuhn 0 siblings, 2 replies; 11+ messages in thread From: Faust! @ 1998-06-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calling C time function from ADA-95 1998-06-07 0:00 Calling C time function from ADA-95 Faust! @ 1998-06-06 0:00 ` Matthew Heaney 1998-06-08 0:00 ` Charles Hixson 1998-06-07 0:00 ` Markus Kuhn 1 sibling, 1 reply; 11+ messages in thread From: Matthew Heaney @ 1998-06-06 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calling C time function from ADA-95 1998-06-06 0:00 ` Matthew Heaney @ 1998-06-08 0:00 ` Charles Hixson 1998-06-08 0:00 ` Dale Stanbrough 0 siblings, 1 reply; 11+ messages in thread From: Charles Hixson @ 1998-06-08 0:00 UTC (permalink / raw) To: Matthew Heaney 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calling C time function from ADA-95 1998-06-08 0:00 ` Charles Hixson @ 1998-06-08 0:00 ` Dale Stanbrough 1998-06-08 0:00 ` Larry Kilgallen 1998-06-09 0:00 ` Markus Kuhn 0 siblings, 2 replies; 11+ messages in thread From: Dale Stanbrough @ 1998-06-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calling C time function from ADA-95 1998-06-08 0:00 ` Dale Stanbrough @ 1998-06-08 0:00 ` Larry Kilgallen 1998-06-09 0:00 ` Markus Kuhn 1 sibling, 0 replies; 11+ messages in thread From: Larry Kilgallen @ 1998-06-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calling C time function from ADA-95 1998-06-08 0:00 ` Dale Stanbrough 1998-06-08 0:00 ` Larry Kilgallen @ 1998-06-09 0:00 ` Markus Kuhn 1998-06-09 0:00 ` Charles Hixson 1 sibling, 1 reply; 11+ messages in thread From: Markus Kuhn @ 1998-06-09 0:00 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calling C time function from ADA-95 1998-06-09 0:00 ` Markus Kuhn @ 1998-06-09 0:00 ` Charles Hixson 1998-06-09 0:00 ` Markus Kuhn 0 siblings, 1 reply; 11+ messages in thread From: Charles Hixson @ 1998-06-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calling C time function from ADA-95 1998-06-09 0:00 ` Charles Hixson @ 1998-06-09 0:00 ` Markus Kuhn 1998-06-09 0:00 ` Charles Hixson 0 siblings, 1 reply; 11+ messages in thread From: Markus Kuhn @ 1998-06-09 0:00 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calling C time function from ADA-95 1998-06-09 0:00 ` Markus Kuhn @ 1998-06-09 0:00 ` Charles Hixson 1998-06-12 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 11+ messages in thread From: Charles Hixson @ 1998-06-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calling C time function from ADA-95 1998-06-09 0:00 ` Charles Hixson @ 1998-06-12 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 11+ messages in thread From: Larry Kilgallen @ 1998-06-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calling C time function from ADA-95 1998-06-07 0:00 Calling C time function from ADA-95 Faust! 1998-06-06 0:00 ` Matthew Heaney @ 1998-06-07 0:00 ` Markus Kuhn 1 sibling, 0 replies; 11+ messages in thread From: Markus Kuhn @ 1998-06-07 0:00 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~1998-06-12 0:00 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-06-07 0:00 Calling C time function from ADA-95 Faust! 1998-06-06 0:00 ` Matthew Heaney 1998-06-08 0:00 ` Charles Hixson 1998-06-08 0:00 ` Dale Stanbrough 1998-06-08 0:00 ` Larry Kilgallen 1998-06-09 0:00 ` Markus Kuhn 1998-06-09 0:00 ` Charles Hixson 1998-06-09 0:00 ` Markus Kuhn 1998-06-09 0:00 ` Charles Hixson 1998-06-12 0:00 ` Larry Kilgallen 1998-06-07 0:00 ` Markus Kuhn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox