How to convert an Fixed_Point to to an Integer ?

How to convert an Fixed_Point to to an Integer ?

[Jerry van Dijk]

Hopefully this newsfeed will work...

The question really is: how do I convert an Ada.Calendar.Time (ie a
Duration, ie a
ordinary fixed_point type) to an Integer representing the nearest number of
seconds.
like:

	Num_Seconds : Integer;

	Num_Seconds := To_Integer (Ada.Calendar.Clock);

	function To_Integer (T : Time) returns Integer is
	begin
		???
	end To_Integer;

-- 
+----------------+------------------------+
| Jerry van Dijk | email: jvandyk@ibm.net |
|   Consultant   |        Team Ada        |
| Ordina Finance | *JerryWare HQ* Holland |
+----------------+------------------------+

Re: How to convert an Fixed_Point to to an Integer ?

[Jerry van Dijk]

To prevent further mail pointer out the obvious (not working) answer:

GNAT 3.05 (960607) Copyright 1991-1996 Free Software Foundation, Inc.

Compiling: oops.adb (source file time stamp: 1996-12-23 12:15:28)

     1. with Ada.Calendar; use Ada.Calendar;
     2.
     3. procedure Oops is
     4.    Now      : Time;
     5.    The_Time : Integer;
     6. begin
     7.    Now := Clock;
     8.    The_Time := Integer (Now);
                                |
        >>> illegal operand for numeric conversion

     9. end Oops;

RE: How to convert an Fixed_Point to to an Integer ?

[Larry Kilgallen]

In article <01bbf058$cbdbf980$LocalHost@jerryware>, "Jerry van Dijk" <jvandyk@ibm.net> writes:

> The question really is: how do I convert an Ada.Calendar.Time (ie a
> Duration, ie a ordinary fixed_point type) to an Integer representing
> the nearest number of seconds.

I think you may have the question wrong then.

Looking in 9.6 (10) of the Ada 95 standard, I see no indication that
Ada.Calendar.Time is a Duration.  In fact, Ada.Calendar.Time seems to
be specified as "private", which should mean that except for code within
Ada.Calendar or its children, there is no hope of converting a value
of type Ada.Calendar.Time to anything else other than by using features
provided for conversion by Ada.Calendar (there seem to be several).

Larry Kilgallen

P.S. I have this problem in society too.  I tell businesses that some
     personal information is private, and they say "We understand, but
     tell us.  You can trust us."  Right !!!  The root concept is that
     private means I am only telling family.

Re: How to convert an Fixed_Point to to an Integer ?

[Robert Dewar]

In article <01bbf058$cbdbf980$LocalHost@jerryware>, "Jerry van Dijk" <jvandyk@ib
m.net> writes:

> The question really is: how do I convert an Ada.Calendar.Time (ie a
> Duration, ie a ordinary fixed_point type) to an Integer representing
> the nearest number of seconds.


Well obviously Time is really a private type, so you are talking about doing
something very implementation dependent and nasty here. Presumably you are
using GNAT, and have taken an "illegal" peek at the private part of Calendar,
where sure enough Time is a derived type of Duration.

You will have to use Unchecked conversion to a type that has exactly the
same range and delta as duration, you could use duration itself for this
purpose. Then just do a normal conversion to seconds and you have the result
(the number of seconds since the base, which is often, but not always, the
Unix epoch at the start of 1970).

But really, you should ask yourself if you want to do this. The resulting
code is highly non-portable and conceptually wrong.

Re: How to convert an Fixed_Point to to an Integer ?

[Eric Miller]

Jerry van Dijk wrote:
> The question really is: how do I convert an Ada.Calendar.Time (ie a
> Duration, ie a
> ordinary fixed_point type) to an Integer representing the nearest number of
> seconds.

Well, first you have to ask the question "seconds since when?"

If the answer is "since the beginning of the day," you can use a call to
Ada.Calendar.Seconds and convert that to an integer.

If it's since some other date, you'll need to call Ada.Calendar.Day,
.Month, and .Year and do some multiplication.

Cheers,

Eric

Re: How to convert an Fixed_Point to to an Integer ?

[Jerry van Dijk]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.851351937@merv>...

> Well obviously Time is really a private type, so you are talking about
doing
> something very implementation dependent and nasty here.

Hmmmm, I don't know. The idea behind encapsulation is protecting the client
code
against changes in implementation, not preventing anyone to assign the
number of
seconds since the epoch to an Integer :-)

The real problem is that there is no conversion operation offered for the
type.

So I solved it by putting these conversion operation in a child of
Ada.Calender:

package Ada.Calendar.Posix is

   type Time_T is mod 2 ** Integer'Size;

   function Clock return Time_T;

   function To_Time (Date : Time_T) return Ada.Calendar.Time;
   function To_Time_T (Date : Ada.Calendar.time) return Time_T;

end Ada.Calendar.Posix;

package body Ada.Calendar.Posix is

   function Clock return Time_T is
   begin
      return To_Time_T (Ada.Calendar.Clock);
   end Clock;

   function To_Time (Date : Time_T) return Ada.Calendar.Time is
   begin
      return Ada.Calendar.Time (Date);
   end To_Time;

   function To_Time_T (Date : Ada.Calendar.Time) return Time_T is
   begin
      return Time_T (Date);
   end To_Time_T;

end Ada.Calendar.Posix;

> You will have to use Unchecked conversion to a type that has exactly the
> same range and delta as duration, you could use duration itself for this
> purpose.

Yes, but talking about messy...

> But really, you should ask yourself if you want to do this. The resulting
> code is highly non-portable and conceptually wrong.

Well, I am writing a more-or-less POSIX-like binding for use with
GNAT/DJGPP.
And that code is inherently non-portable anyway. On the other hand, it does
wonders for the portability of my code between GNAT/Linux and GNAT/DOS :-)

Thanks everyone, for the replies.

Jerry.

P.S. Although the newsfeed on jvdsys.nextjk.stuyts.nl is down, I can still
be
       reached there.

Re: How to convert an Fixed_Point to to an Integer ?

[Robert Dewar]

Jerry van Dijk said

Hmmmm, I don't know. The idea behind encapsulation is protecting the client
code against changes in implementation, not preventing anyone to assign the
number of seconds since the epoch to an Integer :-)

  You are confused. The notion of time has nothing whatsoever to do
  with the epoch which is a unix specific notion that might or might not
  have something to do with the implementation of Time.

  The proper way to get the number of seconds from the epoch to now is

     Integer (Calendar.Clock - Epoch_Time);

  where Epoch_Time is a constant declared as something like
 
     Epoch_Time : constant Time := Calendar.Time_Of (1970,1,1,0.0);

  This approach is clean, and correct Ada and completely portable. Why would
  you want to consider anything else. As I said before you have lead yourself
  astray looking at the private part of Calendar.

So I solved it by putting these conversion operation in a child of
Ada.Calender:

   YECH! A horrible solution, which is completely non-portable. Implementations
   do not have to permit you to compile grand-children of Ada, and indeed, GNAT
   does NOT permit you to do so. Yes, you can use the switch -gnatg to compile
   such a unit, but as soon as you use -gnatg, you no longer have correct
   Ada 95 compiler semantics, the -gnatg switch is definitely intended only
   for implementors!

The conversions you are looking for make no sense in the general case, and
the operations in your Posix child are very implemenbtation specific, and
have no business being a child of Calendar in any case. It is perfectly
reasonable to implement this package without any access to the private
part of Calendar as a separate user level package, and that is what you
should do!

P.S. can you try to keep your lines to 80 chars, thanks

Re: How to convert an Fixed_Point to to an Integer ?

[Norman H. Cohen]

Robert Dewar wrote:

>   The proper way to get the number of seconds from the epoch to now is
> 
>      Integer (Calendar.Clock - Epoch_Time);
> 
>   where Epoch_Time is a constant declared as something like
> 
>      Epoch_Time : constant Time := Calendar.Time_Of (1970,1,1,0.0);
> 
>   This approach is clean, and correct Ada and completely portable. 

Well, it was completely portable on New Year's Day in 1970, but hasn't
been since then, since Calendar.Clock - Epoch_Time is of type Duration,
whose range is allowed to be as small as -86_400.0 .. 86_400.0, i.e.
plus or minus one day (RM 9.6(27)).

(Then again, before 1983, I suppose ANY Ada program was vacuously
portable to all existing Ada compilers! ;-) )

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: How to convert an Fixed_Point to to an Integer ?

[Robert Dewar]

"Well, it was completely portable on New Year's Day in 1970, but hasn't
been since then, since Calendar.Clock - Epoch_Time is of type Duration,
whose range is allowed to be as small as -86_400.0 .. 86_400.0, i.e.
plus or minus one day (RM 9.6(27))."


True enough, of course in all GNAT compilers, Duration has a vrey large
range (it is 64 bit signed in units of nanoseconds). I wonder whether
there really will be Ada 95 compilers with narrow ranges ....

So a truly portable solution would have to use a loop ...

Re: How to convert an Fixed_Point to to an Integer ?

[Jerry van Dijk]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.851441337@merv>...

>   You are confused. The notion of time has nothing whatsoever to do
>   with the epoch which is a unix specific notion that might or might
not
>   have something to do with the implementation of Time.

Yes, you are right. To much Unix on the mind ? Anyway I think I
an just going leave Calendar alone and simply use the C library
function call.

>   The proper way to get the number of seconds from the epoch to now
is
> 
>      Integer (Calendar.Clock - Epoch_Time);
> 
>   where Epoch_Time is a constant declared as something like
>  
>      Epoch_Time : constant Time := Calendar.Time_Of (1970,1,1,0.0);

Yep, but I will await your reaction to Norman's comment first.

> So I solved it by putting these conversion operation in a child of
> Ada.Calender:
> 
>    YECH! A horrible solution, which is completely non-portable.

I know, that's why I am looking for another solution.

BTW do you know of plans to upgrade the POSIX spec to Ada95 ?

> P.S. can you try to keep your lines to 80 chars, thanks

Hmmm, I've set the line limit to 72...

Thanks for your input!
Jerry.

Re: How to convert an Fixed_Point to to an Integer ?

[Robert Dewar]

iJerry said (wrt my solution of the epoch problem)

"Yep, but I will await your reaction to Norman's comment first."

Well your original solution was even more GNAT specific :-)

The question is whether or not there are Ada 95 compilers (other than
GNAT) that actually have a very limited range for Duration. It is quite
possible that the answer is yes. In GNAT, 64-bit integer and 64-bit
fixed-point arithmetic are always available on all targets, and Duration
is a 64-bit fixed-point value.

However, surprisingly, many Ada 83 technologies did not support integer
values longer than 32 bits, so it would not surprise me if there are
Ada 95 compilers around with 32-bit Duration (it is *just* possible to
squeeze Duration in to 32 bits -- by design). I feel that taking advantage
of this permission to provide a very restricted duration is unfortunate,
but if you want to write completely Rm-portable code, then Norman is
right, you should take this into account.

The way to do this is to write a loop using Time_Of that goes forward one
year at a time, accumulating seconds, starting with 1970, till you get to
the year you want. Of course you could make this a memo function so that
once it knew the number of seconds to the start of a given year, it would
not compute it again.

Note that if you use Integer as the result, you are also creating another
source of potential portability problems. In GNAT, Integer is always at
least 32 bits, at least on all currnt targets (it is actually the sam
as the C int in length), but there may be Ada 95 compilers with smaller
Integer types, so really you should define an appropraite range type as
the result of this seconds-from-the-Unix-epoch call.

Better would be to make your program independent of this curious Unix-based
notion of the Epoch all together.

This being said, using the C routine is quite appropriate in this case anyway,
since obviously you are doing something rather Unix specific ....

Re: How to convert an Fixed_Point to to an Integer ?

[Keith Thompson]

In <dewar.851480526@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> True enough, of course in all GNAT compilers, Duration has a vrey large
> range (it is 64 bit signed in units of nanoseconds). I wonder whether
> there really will be Ada 95 compilers with narrow ranges ....

Yes, under ObjectAda the range of type Duration is about +/-131072.0.
(It's a 32-bit type.)

> So a truly portable solution would have to use a loop ...

Actually, a truly portable solution could just use an algorithm to
compute the number of days between two given dates and then account for
the seconds.  It's a bit more complicated than it should need to be,
but there's no portability problem.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: How to convert an Fixed_Point to to an Integer ?

[Robert Dewar]

Keith said, replying to me

> So a truly portable solution would have to use a loop ...

Actually, a truly portable solution could just use an algorithm to
compute the number of days between two given dates and then account for
the seconds.  It's a bit more complicated than it should need to be,
but there's no portability problem.



Sure, you can always do everythnig yourself!
The reason I suggested a loop through years is that way you do much
less work yourself.

Re: How to convert an Fixed_Point to to an Integer ?

[Norman H. Cohen]

Referring to the portable calculation of the number of seconds since the
start of 1970, Robert Dewar wrote:

> The way to do this is to write a loop using Time_Of that goes forward one
> year at a time, accumulating seconds, starting with 1970, till you get to
> the year you want. Of course you could make this a memo function so that
> once it knew the number of seconds to the start of a given year, it would
> not compute it again.

A more efficient, and to me conceptually simpler, approach is to split
the Time value returned by Calendar.Clock into a year, month, day of
month, and number of seconds since midnight, and use those values to
calculate the number of seconds.  Accounting for leap years introduces a
slight complication, and this approach does not account for leap
seconds, but I'm not sure how Unix systems deal with leap seconds
either.  (Does the current Unix time include all leap seconds since the
start of 1970?  If not, is it possible for a file created during a leap
second to have the same time stamp as a file created a second later, and
a later time stamp than a file created half a second later?)

Here's the calculation, basically what an earlier message referred to as
"calling Split and doing a bunch of multiplications":

package Epoch is


   -- Note: This package works from the beginning of 1970 until the end
of
   --    2099, after which the package Ada.Calendar is no longer usable.
   --    During this period, a year y is a leap year if and only if y
mod 4 = 0.

   -- This package ignores the existence of leap seconds.  That is, the
number
   --    of seconds in previous years is calculated as if leap seconds
did not
   --    exist, and the behavior of the function Seconds_Since_Epoch
during a
   --    leap second depends on the value returned by Ada.Calendar.Clock
during
   --    a leap second, which is not defined by the Ada standard.


   -- Some fundamental constants:

   Days_Per_Ordinary_Year : constant := 365;
   Days_Per_Leap_Year     : constant := 366;
   Seconds_Per_Day        : constant := 86_400;


   -- A compile-time calculation of the number of seconds from the start
of
   --   1970 to the start of 2100:

   Max_Years          : constant := 2100 - 1970;
   Max_Leap_Years     : constant := (2100 - 1969) / 4;
                           -- The number of leap years since 1970 but
before
                           --    year y is given by (y-1969)/4.
                           --    ("Proof": The value of the integer
quotient
                           --    increases by 1 whenever y increases to
a value
                           --    such that (y-1969) mod 4 = 0, i.e.,
whenever
                           --    y mod 4 = 1, i.e., whenver y-1 is a
leap year.)
   Max_Ordinary_Years : constant := Max_Years - Max_Leap_Years;
   Max_Days           : constant :=
                           Max_Ordinary_Years*Days_Per_Ordinary_Year +
                           Max_Leap_Years*Days_Per_Leap_Year;
   Max_Seconds        : constant := Max_Days * Seconds_Per_Day;


   -- The principal facilities provided by the package:

   type Seconds_Type is delta Duration'Delta range 0.0 ..
1.0*Max_Seconds;
      -- multiplication by 1.0 converts universal_integer to
universal_real

   function Seconds_Since_Epoch return Seconds_Type;
      -- Returns the number of seconds since the start of 1970.

end Epoch;


with Ada.Calendar;

package body Epoch is

   subtype Month_Number is Ada.Calendar.Month_Number;

   January  : constant Month_Number := Month_Number'First;
   February : constant Month_Number := Month_Number'Succ(January);
   December : constant Month_Number := Month_Number'Last;

   type Days_Type is range 0 .. Max_Days;
      -- Use of type Integer would not be portable to implementations
for
      --    which Integer'Size = 16, since Max_Days > 2**15-1

   Days_In_Month     : array (Month_Number) of Days_Type :=
                          (31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30,
31);
                          -- Gives the number of days in the given month
                          --    in an ordinary year.

   Days_Before_Month : array (Month_Number) of Days_Type;
                          -- Gives the number of days since the start of
the
                          --    year occurring before the given month in
an
                          --    ordinary year; initialized during
package-body
                          --    elaboration.


   function Seconds_Since_Epoch return Seconds_Type is

      This_Year              : Ada.Calendar.Year_Number;
      This_Month             : Month_Number;
      This_Day               : Ada.Calendar.Day_Number;
      Seconds_Since_Midnight : Ada.Calendar.Day_Duration;
      Previous_Years         : Natural;
      Previous_Leap_Years    : Natural;
      Days_Before_This_Year  : Days_Type;
      Days_Before_This_Month : Days_Type;
      Days_Before_Today      : Days_Type;
      Seconds_Before_Today   : Seconds_Type;

   begin

      Ada.Calendar.Split
         (Ada.Calendar.Clock,
          This_Year,
          This_Month,
          This_Day,
          Seconds_Since_Midnight);

      Previous_Years := This_Year - 1970;

      Previous_Leap_Years := (This_Year - 1969) / 4;
         -- See declaration of Max_Leap_Years in package declaration.

      Days_Before_This_Year :=
         Days_Type(Previous_Years) * Days_Per_Ordinary_Year +
         Days_Type(Previous_Leap_Years);
         -- i.e., number of ordinary days + number of February 29ths

      if This_Year mod 4 = 0 and This_Month > February then
         Days_Before_This_Month :=
            Days_Before_This_Year + Days_Before_Month(This_Month) + 1;
            -- + 1 is for February 29
      else
         Days_Before_This_Month :=
            Days_Before_This_Year + Days_Before_Month(This_Month);
      end if;

      Days_Before_Today := Days_Before_This_Month + Days_Type(This_Day -
1);

      Seconds_Before_Today :=
         Seconds_Per_Day * Seconds_Type(Days_Before_Today);

      return Seconds_Before_Today +
Seconds_Type(Seconds_Since_Midnight);

   end Seconds_Since_Epoch;


begin  -- initialization of Days_Before_Month


   Days_Before_Month(January) := 0;
   for Month in February .. December loop
      Days_Before_Month(Month) :=
         Days_Before_Month(Month-1) + Days_In_Month(Month-1);
   end loop;


end Epoch;

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: How to convert an Fixed_Point to to an Integer ?

[Jerry van Dijk]

Norman,

Norman H. Cohen <ncohen@watson.ibm.com> wrote in article
<32C2A408.53B8@watson.ibm.com>...

> slight complication, and this approach does not account for leap
> seconds, but I'm not sure how Unix systems deal with leap seconds
> either

Good question. My normal Unix bible (Stevens, 'Advanced programming in
the
Unix Enviroment, AW, 9th printing, july 1995) keeps almost silent about
it.

But on page 155 Stevens says:

	"struct tm {	/* a broken down time */
		int tm_sec;	/* Seconds after the minute: [0, 61] */
	...

	The reason that seconds can be greater than 59 is to allow for leap
	seconds."

And as the DJGPP info documents this fields as [0, 60] I am reasonable
convinced that leaps are taken care of in both systems.

> package Epoch is
> 
> 
>    -- Note: This package works from the beginning of 1970 until the
end of
>    --    2099, after which the package Ada.Calendar is no longer
usable.
>    --    During this period, a year y is a leap year if and only if y
> mod 4 = 0.

Gee, and I only asked about it... Thanks Norman!

Jerry,

Leap seconds in Unix time (was: Re: How to convert an Fixed_Point to to an Integer ?)

[Norman H. Cohen]

Jerry van Dijk wrote:

> But on page 155 Stevens says:
> 
>         "struct tm {    /* a broken down time */
>                 int tm_sec;     /* Seconds after the minute: [0, 61] */
>         ...
> 
>         The reason that seconds can be greater than 59 is to allow for leap
>         seconds."
> 
> And as the DJGPP info documents this fields as [0, 60] I am reasonable
> convinced that leaps are taken care of in both systems.

If the mappings between "struct tm" times and seconds-since-epoch times
are one-to-one, this suggests that the seconds-since-the-epoch
calculations somehow account for all the leap seconds since the start of
1970.  Since these leap seconds occur sporadically, based on empirical
observations of the earth's rotation, computations of
seconds-since-epoch from struct tm values or from the system clock, and
computations of struct tm values from seconds-since-epoch values, would
require a data base of the dates since 1970 on which there were leap
seconds.

Can anyone confirm whether this is, indeed, how things work?

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: How to convert an Fixed_Point to to an Integer ?

[Steve Jones - JON]

Dave Barnes <barnesd@it.postoffice.co.uk> writes:

> 
> Steve Jones - JON wrote:
> > 
> > 
> > Each century is not a leap year (eg 1900 wasn't) but Millenia ARE leap years
> > so 2000 will be one. 
> > 
> 
> Where has *this* come from? 
> 
> The rule is simply divisible by 4 except if a multiple of 100 when must be divisible by 
> 400. So 1900 wasn't, 2000 will be and the year 3000 won't be a leap year (but I really 
> don't give a damn about the last one). 

Doh! Okay I got in horribly wrong... Bugger. But luckily the one time I 
actually had to write some date type handling stuff I must have read
up on it rather than listening to the elves as the code works until INTEGER
runs out (in years both ways :) nothing like excess when being careful) so 
for those planning to travel in Sheffield in the year 2400 you will be Okay:)

I hate being found to be stupid :(

The "rule" came from my imagination and a heavy christmas break :)
-- 
----------------------------------------------------------------------------
Steve Jones                     | "Atticus says that carring a gun is a sure
Eurocontrol Experimental Centre |  way to get shot" -- Scout Finch in
                                | To Kill a Mocking Bird by Harper Lee
----------------------------------------------------------------------------
Do not add me to any commercial mailing lists, all unsolicted commercial
email will be billed at my current rate.
----------------------------------------------------------------------------

Re: How to convert an Fixed_Point to to an Integer ?

[Michael F Brenner]

The previous article was submitted stating that the author was not
sure whether the Year 2000 was a leap year. This not being sure is
actually a portion of the problem referred to as the Year 2000 problem.


The year 2000 is a leap year. The three rules which the Gregorian 
calendar uses to determine leap year are as follows:

      1.Years divisible by four are leap years, unless...
      2.Years also divisible by 100 are not leap years, except...
      3.Years divisible by 400 are leap years.

Therefore, the year 2000 is a leap year according to rule number three.

mikeb@mitre.org Mike Brenner at The MITRE Corporation

Re: How to convert an Fixed_Point to to an Integer ?

[Mike Young]

Norman H. Cohen wrote:
> 
>    -- Note: This package works from the beginning of 1970 until the end
> of
>    --    2099, after which the package Ada.Calendar is no longer usable.
>    --    During this period, a year y is a leap year if and only if y
> mod 4 = 0.

======
I believe the year 2000 is *not* a leap year. I recall vaguely they skip
a leap year every 200 years, such that it's a leap year if the number is
evenly divisible by 4 and not by 200. You may want to verify this before
casting this in code. The net result is to cause all calc's spanning
2/28/2000 to be reported incorrectly. Most specifically,
Previous_Leap_Years needs to be adjusted down one for dates beyond
2/28/2000.

Mike.

2000 is a leap year (was: How to convert an Fixed_Point to to an Inte)

[Larry Kilgallen]

In article <32C78CD9.3AC9@mcs.com>, Mike Young <mikey@mcs.com> writes:

> ======
> I believe the year 2000 is *not* a leap year. I recall vaguely they skip
> a leap year every 200 years, such that it's a leap year if the number is
> evenly divisible by 4 and not by 200.

Year 2000 certainly _is_ a leap year, as the rule laid down by the Pope
many years ago (after receiving advice of leading scientists of the time)
was:

	Years which are even multiples of 4 - yes except...
	Years which are even multiples of 100 - no except...
	Years which are even multiples of 400 - yes

Larry Kilgallen
Not an official spokesman for the Roman Catholic Church :-)

Re: How to convert an Fixed_Point to to an Integer ?

[Steve Jones - JON]

Mike Young <mikey@mcs.com> writes:

> 
> Norman H. Cohen wrote:
> > 
> >    -- Note: This package works from the beginning of 1970 until the end
> > of
> >    --    2099, after which the package Ada.Calendar is no longer usable.
> >    --    During this period, a year y is a leap year if and only if y
> > mod 4 = 0.
> 
> ======
> I believe the year 2000 is *not* a leap year. I recall vaguely they skip
> a leap year every 200 years, such that it's a leap year if the number is
> evenly divisible by 4 and not by 200. You may want to verify this before
> casting this in code. The net result is to cause all calc's spanning
> 2/28/2000 to be reported incorrectly. Most specifically,
> Previous_Leap_Years needs to be adjusted down one for dates beyond
> 2/28/2000.
> 
> Mike.


Each century is not a leap year (eg 1900 wasn't) but Millenia ARE leap years
so 2000 will be one. This has nicely made writting calendar progs a little
simpler as you don't have to do a /100 check for a limited span product
(eg 1970 -> 2099).  I'd guess he stops at 2099 for just that reason. The check
is quite simple but why add code when a comment suffices ?

-- 
----------------------------------------------------------------------------
Steve Jones                     | "Atticus says that carring a gun is a sure
Eurocontrol Experimental Centre |  way to get shot" -- Scout Finch in
                                | To Kill a Mocking Bird by Harper Lee
----------------------------------------------------------------------------
Do not add me to any commercial mailing lists, all unsolicted commercial
email will be billed at my current rate.
----------------------------------------------------------------------------

Re: How to convert an Fixed_Point to to an Integer ?

[Dave Barnes]

Steve Jones - JON wrote:
> 
> 
> Each century is not a leap year (eg 1900 wasn't) but Millenia ARE leap years
> so 2000 will be one. 
> 

Where has *this* come from? 

The rule is simply divisible by 4 except if a multiple of 100 when must be divisible by 
400. So 1900 wasn't, 2000 will be and the year 3000 won't be a leap year (but I really 
don't give a damn about the last one). 

Dave

Dave Barnes                        barnesd@it.postoffice.co.uk
SSG, Quality Support

* The views I express are mine. They may change at short notice *

Re: How to convert an Fixed_Point to to an Integer ?

[Jacques Rouillard]

In article <2safqwb3jc.fsf@hpodid2.eurocontrol.fr>, Steve Jones - JON
<jon@hpodid2.eurocontrol.fr> wrote:


> Each century is not a leap year (eg 1900 wasn't) but Millenia ARE leap years
> so 2000 will be one. This has nicely made writting calendar progs a little
> simpler as you don't have to do a /100 check for a limited span product
> (eg 1970 -> 2099).  I'd guess he stops at 2099 for just that reason. The check
> is quite simple but why add code when a comment suffices ?

Not only millenia but all centuries multiple of 400. 2000 will be the
second time it happens since the 1582 reform. 

Yours,

Jacques

--
Jacques Rouillard t33(0)491054342 f33(0)491700659 e rouillard@acm.org
USA http://vhdl.org/~rouillard   EU http://ismea.imt-mrs.fr/~rouillar
---------------------------------------------------------------------
    VOUS POUVEZ MAINTENANT PASSER SANS DANGER AU MESSAGE SUIVANT

Re: How to convert an Fixed_Point to to an Integer ?

[Keith Thompson]

In <32C78CD9.3AC9@mcs.com> Mike Young <mikey@mcs.com> writes:
[misinformation about leap year rules]

Folks, before you post anything about leap year rules, please read the
Calendar FAQ at <http://www.pip.dknet.dk/~pip10160/calendar.html>.

The rules for the Gregorian Calendar (the one we currently use) are in
<http://www.pip.dknet.dk/~pip10160/calendar.faq1.txt>, section 2.2.

> 2.2.1. What years are leap years?
> ---------------------------------
> 
> The Gregorian calendar has 97 leap years every 400 years:
> 
>         Every year divisible by 4 is a leap year.
>         However, every year divisible by 100 is not a leap year.
>         However, every year divisible by 400 is a leap year after all.
> 
> So, 1700, 1800, 1900, 2100, and 2200 are not leap years. But 1600,
> 2000, and 2400 are leap years.
[...]

A 4000-year rule has been proposed but not officially adopted.

(Which reminds me -- I need to pick up some Purina Peeve Chow.  8-)})

(Warning: I've redirected followups to /dev/null.  If you really feel
you have something relevant to add, you'll need to edit the Newsgroups:
header.)

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: 2000 is a leap year (was: How to convert an Fixed_Point to to an Inte)

[Mike Paley]

com> <32C78CD9.3AC9@mcs.com> <1996Dec30.071509.1@eisner>
Message-ID: <867381119wnr@paley.demon.co.uk>
Date: Thursday, Jan 02, 1997 17.37.01
Organization: Not organised yet
Reply-To: mike@paley.demon.co.uk
X-Newsreader: Newswin Alpha 0.7
Lines:  19

In article: <1996Dec30.071509.1@eisner>  kilgallen@eisner.decus.org (Larry 
Kilgallen) writes:
:) Year 2000 certainly _is_ a leap year, as the rule laid down by the Pope
:) many years ago...

Just hope he's told the sun to cooperate !

-- 
Comm again, Mike. 

If I have offended anyone, please accept my apologies. To prevent this 
re-occurring, next time you read one of my posts, wear a blindfold.

Ex Turnpike user.

If you want to see the rest of this sig. file or find out more about me, 
have a look at http://www.paley.demon.co.uk/ [1996:11:30]