Re: C date package

Re: C date package

[Geoff Bull]

here are some calendar links:

http://emr.cs.uiuc.edu/home/reingold/calendar-book/calendar-links.shtml

Dale Stanbrough wrote:
> i would disagree. In the same way that we use GMT as  standard for time, we
> should be able to come up with a time based system that underlies the
> various views that are needed.
> 
> After all, a date that is 30,000 days ago -is- 30,000 days ago, no matter
> what calendar is used.
> 
> 1752's interpretation could then be viewed by using a gregorian calendar
> package, or a julian calendar package (i presume this is where the
> difference is...).

Re: C date package

[Geoff Bull]

Geoff Bull wrote:
> Dale Stanbrough wrote:
> > i would disagree. In the same way that we use GMT as  standard for time,

Isn't GMT defunct?

> > we should be able to come up with a time based system that underlies the
> > various views that are needed.

Sounds simple, just base time in the primary time standard: TAI 
(International Atomic Time). Ada.Real_Time is already based on TAI.
And then you layer, Gregorian, Julian, Jewish or whatever calendar you want
on top of that ?

Trouble is people will start arguing about resolution and range.
Do we try to cover needs of astronomers, real time programmer's and
the rest of us with one time abstraction.

The current Ada.Calendar is pretty weak - just reports an implementation
defined time - local time on my system.


> >
> > After all, a date that is 30,000 days ago -is- 30,000 days ago, no matter
> > what calendar is used.

In a sense this isn't true.
30,000 rotations of the earth is /= 30,000 * 24 * 60 * 60 seconds.

The problem with dealing with time and date is that you are mixing up
two concepts:
the lapse of a number of fixed size seconds (fixed by definition),
the lapse of number of varying size days (in terms of number of seconds).

Re: C date package

[Robert Dewar]

In article <39178DEA.FD2C20FA@research.canon.com.au>,
  Geoff Bull <geoff@research.canon.com.au> wrote:

> The current Ada.Calendar is pretty weak - just reports an
> implementation defined time - local time on my system.

Well that seems pretty strong to me, given that the design point
of the Ada.Calendar package is precisely to report the commonly
used local time on your system.

Almost any package is weak if you start expecting it to do
things completely outside what it was designed for (for
example I have found Ada.Numerics.Generic_Elementary_Functions
virtually useless for doing computations on arbitrary precision
arithmetic quantities).



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C date package

[Geoff Bull]

Oops, I posted to comp.lang.ada by mistake!
This was a thread on team-ada discussing which started with
the "2038 bug".

Robert Dewar wrote:
> 
> In article <39178DEA.FD2C20FA@research.canon.com.au>,
>   Geoff Bull <geoff@research.canon.com.au> wrote:
> 
> > The current Ada.Calendar is pretty weak - just reports an
> > implementation defined time - local time on my system.
> 
> Well that seems pretty strong to me, given that the design point
> of the Ada.Calendar package is precisely to report the commonly
> used local time on your system.
> 
> Almost any package is weak if you start expecting it to do
> things completely outside what it was designed for


Fair enough, weak was probably the wrong word (maybe I should used "basic")
- it doesn't even split out hours and minutes.

And it would be reasonable to believe that anything in the
Ada standard meets the design goals.
But I don't even see where the RM says it reports local time, UTC
UT1, TAI or whatever. Of course this is documented, as required,
in the Gnat reference manual.

9.6 23.The time base associated with the type Time of package
       Calendar is implementation defined.

9.6 24.The functions Year, Month, Day, and Seconds return the
       corresponding values for a given value of the type Time,
       as appropriate to an implementation-defined timezone.

So if I run two different Ada compilers on my system they are quite within
their rights to report different times.

A function that reported the offset from UTC, e.g., would be useful.
I guess implementations that didn't know about timezones would
have to be permitted to always return 0.
It would be a bit much to ask for the weekday name when ther is no
awareness of the current locale.

Cheers
Geoff

Re: C date package

[Robert Dewar]

In article <3918BB77.693C70D6@research.canon.com.au>,
  Geoff Bull <geoff@research.canon.com.au> wrote:
> Oops, I posted to comp.lang.ada by mistake!
> This was a thread on team-ada discussing which started with
> the "2038 bug".

> Fair enough, weak was probably the wrong word (maybe I should
> used "basic")
> - it doesn't even split out hours and minutes.

By the way, have a look at the package GNAT.Calendar in GNAT
3.13 which fills in some of the gaps. In fact let me post the
spec here. There is also a GNAT.Calendar.Time_IO that allows
flexible output of times


--  This package extends Ada.Calendar to handle Hour, Minute,
Second,
--  Second_Duration and Day_Of_Week and Day_In_Year from
Calendar.Time.
--  Second_Duration precision depends on the target clock
precision.
--
--  GNAT.Calendar provides the same kind of abstraction found in
--  Ada.Calendar. It provides Split and Time_Of to build and
split a Time
--  data. And it provides accessor functions to get only one of
Hour, Minute,
--  Second, Second_Duration. Other functions are to access more
advanced
--  valueas like Day_Of_Week, Day_In_Year and Week_In_Year.

with Ada.Calendar;
with Interfaces.C;

package GNAT.Calendar is

   type Day_Name is
     (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday,
Sunday);

   subtype Hour_Number         is Natural range 0 .. 23;
   subtype Minute_Number       is Natural range 0 .. 59;
   subtype Second_Number       is Natural range 0 .. 59;
   subtype Second_Duration     is Ada.Calendar.Day_Duration
range 0.0 .. 1.0;
   subtype Day_In_Year_Number  is Positive range 1 .. 366;
   subtype Week_In_Year_Number is Positive range 1 .. 53;

   function Hour        (Date : Ada.Calendar.Time) return
Hour_Number;
   function Minute      (Date : Ada.Calendar.Time) return
Minute_Number;
   function Second      (Date : Ada.Calendar.Time) return
Second_Number;
   function Sub_Second  (Date : Ada.Calendar.Time) return
Second_Duration;
   --  Hour, Minute, Sedond and Sub_Second returns the complete
time data for
   --  the Date (H:M:S.SS). See Ada.Calendar for Year, Month,
Day accessors.
   --  Second_Duration precision depends on the target clock
precision.

   function Day_Of_Week (Date : Ada.Calendar.Time) return
Day_Name;
   --  Return the day name.

   function Day_In_Year (Date : Ada.Calendar.Time) return
Day_In_Year_Number;
   --  Returns the day number in the year. (1st January is day 1
and 31st
   --  December is day 365 or 366 for leap year).

   function Week_In_Year (Date : Ada.Calendar.Time) return
Week_In_Year_Number;
   --  Returns the week number in the year with Monday as first
day of week

   procedure Split
     (Date       : Ada.Calendar.Time;
      Year       : out Ada.Calendar.Year_Number;
      Month      : out Ada.Calendar.Month_Number;
      Day        : out Ada.Calendar.Day_Number;
      Hour       : out Hour_Number;
      Minute     : out Minute_Number;
      Second     : out Second_Number;
      Sub_Second : out Second_Duration);
   --  Split the standard Ada.Calendar.Time data in date data
(Year, Month,
   --  Day) and Time data (Hour, Minute, Second, Sub_Second)

   function Time_Of
     (Year       : Ada.Calendar.Year_Number;
      Month      : Ada.Calendar.Month_Number;
      Day        : Ada.Calendar.Day_Number;
      Hour       : Hour_Number;
      Minute     : Minute_Number;
      Second     : Second_Number;
      Sub_Second : Second_Duration := 0.0)
      return Ada.Calendar.Time;
   --  Returns an Ada.Calendar.Time data built from the date and
time values.

   --  C timeval conversion

   --  C timeval represent a duration (used in Select for
example). This
   --  structure is composed of a number of seconds and a number
of micro
   --  seconds. The timeval structure is not exposed here
because its
   --  definition is target dependent. Interface to C programs
is done via a
   --  pointer to timeval structure.

   type timeval is private;

   function To_Duration (T : access timeval) return Duration;
   function To_Timeval  (D : Duration) return timeval;

private
   --  This is a dummy declaration that should be the largest
possible timeval
   --  structure of all supported targets.

   type timeval is array (1 .. 2) of Interfaces.C.long;

   function Julian_Day
     (Year  : Ada.Calendar.Year_Number;
      Month : Ada.Calendar.Month_Number;
      Day   : Ada.Calendar.Day_Number)
      return  Integer;
   --  Compute Julian day number.
   --
   --  The code of this function is a modified version of
algorithm
   --  199 from the Collected Algorithms of the ACM.
   --  The author of algorithm 199 is Robert G. Tantzen.
end GNAT.Calendar;


--  This package augments standard Ada.Text_IO with facilities
for input
--  and output of time values in standardized format.

package GNAT.Calendar.Time_IO is

   Picture_Error : exception;

   type Picture_String is new String;

   --  This is a string to describe date and time output format.
The string is
   --  a set of standard character and special tag that are
replaced by the
   --  corresponding values. It follows the GNU Date
specification. Here are
   --  the recognized directives :
   --
   --          %    a literal %
   --          n    a newline
   --          t    a horizontal tab
   --
   --          Time fields:
   --
   --          %H   hour (00..23)
   --          %I   hour (01..12)
   --          %k   hour ( 0..23)
   --          %l   hour ( 1..12)
   --          %M   minute (00..59)
   --          %p   locale's AM or PM
   --          %r   time, 12-hour (hh:mm:ss [AP]M)
   --          %s   seconds  since 1970-01-01  00:00:00 UTC
   --                (a nonstandard extension)
   --          %S   second (00..59)
   --          %T   time, 24-hour (hh:mm:ss)
   --
   --          Date fields:
   --
   --          %a   locale's abbreviated weekday name (Sun..Sat)
   --          %A   locale's    full   weekday   name,
variable   length
   --                  (Sunday..Saturday)
   --          %b   locale's abbreviated month name (Jan..Dec)
   --          %B   locale's    full    month    name,
variable    length
   --                  (January..December)
   --          %c   locale's date and time (Sat Nov 04 12:02:33
EST 1989)
   --          %d   day of month (01..31)
   --          %D   date (mm/dd/yy)
   --          %h   same as %b
   --          %j   day of year (001..366)
   --          %m   month (01..12)
   --          %U   week number  of year with  Sunday as first
day  of week
   --                  (00..53)
   --          %w   day of week (0..6) with 0 corresponding to
Sunday
   --          %W   week number  of year with  Monday as first
day  of week
   --                  (00..53)
   --          %x   locale's date representation (mm/dd/yy)
   --          %y   last two digits of year (00..99)
   --          %Y   year (1970...)
   --
   --          By default,  date pads numeric fields with
zeroes.  GNU date
   --          recognizes the following nonstandard numeric
modifiers:
   --
   --          -    (hyphen) do not pad the field
   --          _    (underscore) pad the field with spaces


   ISO_Date      : constant Picture_String;
   US_Date       : constant Picture_String;
   European_Date : constant Picture_String;

   function Image
     (Date    : Ada.Calendar.Time;
      Picture : Picture_String)
      return    String;
   --  Return Date as a string with format Picture.
   --  raise Picture_Error if picture string is wrong

   procedure Put_Time
     (Date    : Ada.Calendar.Time;
      Picture : Picture_String);
   --  Put Date with format Picture.
   --  raise Picture_Error if picture string is wrong

private
   ISO_Date      : constant Picture_String := "%Y/%m/%d";
   US_Date       : constant Picture_String := "%m/%d/%y";
   European_Date : constant Picture_String := "%d/%m/%y";

end GNAT.Calendar.Time_IO;



Sent via Deja.com http://www.deja.com/
Before you buy.

Ada Calendar oddity <was Re: C date package>

[Preben Randhol]

I was looking yesterday in the RM and found that Year in the
Ada.Calendar was defined until 2099 only. I have search on deja, but I
cannot find any reason for it to be defined only to 2099.

Some would claim that 2099 is a long way in the future, but I think it
isn't in all respects.

An example: If I were to make a program for issuing drivers licenses
here in Norway there would be a problem. Well not immediately but in
only 18 years.

The reason is that driver's licenses expires as you get 100 years old. So
mine expires in 2073.

If one wanted to use the Year type in Ada.Calendar for birthday and
expiration date, one would get an constraint error when one issued
drivers licences for these born this year. Wouldn't one?

I may have missed some thing important when I speedily "read" the
Ada.Calendar, but this seems a bit odd to me (the upper limit that is).

-- 
Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/>
         "Det eneste trygge stedet i verden er inne i en fortelling."
                                                      -- Athol Fugard

Re: Ada Calendar oddity <was Re: C date package>

[Robert A Duff]

randhol+nospam@pvv.org (Preben Randhol) writes:

> I was looking yesterday in the RM and found that Year in the
> Ada.Calendar was defined until 2099 only. I have search on deja, but I
> cannot find any reason for it to be defined only to 2099.

The reason for the range 1901..2099 is that leap year calculations are
simpler (and more efficient) in this range -- in this range, all years
divisible by 4 are leap years (including 2000).  1900 and 2100 are not
leap years.

One can argue about whether that's a *good* reason, but it's the reason.

What range would *you* suggest?

If I were designing such a package, I would think about the number of
bits needed to represent the number of seconds (or nanoseconds?) in the
range.

- Bob

Re: Ada Calendar oddity <was Re: C date package>

[Preben Randhol]

On Wed, 10 May 2000 13:44:39 GMT, Robert A Duff wrote:
>randhol+nospam@pvv.org (Preben Randhol) writes:
>
>The reason for the range 1901..2099 is that leap year calculations are
>simpler (and more efficient) in this range -- in this range, all years
>divisible by 4 are leap years (including 2000).  1900 and 2100 are not
>leap years.

Ah I see.

>What range would *you* suggest?

Well that would perhaps depend on the implementation I guess. If one
defined the upper limit to 9999 one would get a very big number trying
to calculate the numbers of seconds from today until say year 7000.

>If I were designing such a package, I would think about the number of
>bits needed to represent the number of seconds (or nanoseconds?) in the
>range.

I think that in this case one needs to use another type for the birth
and expiration date and convert from Ada.Calendar the date of today if one
also wants the date when the license was issued.

-- 
Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/>
         "Det eneste trygge stedet i verden er inne i en fortelling."
                                                      -- Athol Fugard

Re: Ada Calendar oddity <was Re: C date package>

[Charles Hixson]

Preben Randhol wrote:

> -- snip
> >If I were designing such a package, I would think about the number of
> >bits needed to represent the number of seconds (or nanoseconds?) in the
> >range.
>
> I think that in this case one needs to use another type for the birth
> and expiration date and convert from Ada.Calendar the date of today if one
> also wants the date when the license was issued.
>
> --
> Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/>
>          "Det eneste trygge stedet i verden er inne i en fortelling."
>                                                       -- Athol Fugard

It seems to me that it is a mistake to include seconds, much less any smaller
unit, in the calendar date.  I'm not sure that minutes is justified, but if
one uses a 64 bit number then it wouldn't seem to cause any problems.
(Calendar corrections for seconds are SO much more common than corrections for
minutes!)  2^63 minutes would seem to express any particular time that one
would want to talk about.
Perhaps Calendar and Time could be two separate packages, each using a 64-bit
number as their base, one based on days and the other based on
?nano?-seconds.  Or time could be defined with the top 32 bits being
equivalent to the bottom 32 bits of Calendar, and the "lower" 32 bits being a
floating point number guaranteed to be less than 1, a fractional number of
minutes.  This would allow DateTime to be a 96 bit number good for (nearly)
everything.  This would make formatting the I/O a bit of work, but would make
date and time calculations very simple.  It seems to me that one would gain on
one would more than make up for what one would loose on the other (I calculate
with Time-s a lot more than I display them).

Re: Ada Calendar oddity <was Re: C date package>

[Geoff Bull]

Charles Hixson wrote:
>
> It seems to me that it is a mistake to include seconds, much less any smaller
> unit, in the calendar date.

Astronomers and real time programers, e.g., might not agree
with you. Although, of course, the latter group are catered
for with Ada.Real_Time.

>  I'm not sure that minutes is justified, but if

Depends on what requirement you are trying to meet.

> one uses a 64 bit number then it wouldn't seem to cause any problems.

Elsewhere it has already been stated that no more than 32 bits
is essential (I have no opinion on this0.

> Perhaps Calendar and Time could be two separate packages, each using a 64-bit
> number as their base, one based on days and the other based on
> ?nano?-seconds.

This is perhaps not a bad idea, because seconds and days are
different concepts, one being a fixed period of time, the other
being the variable amount of time for one rotation of the earth
(either wrt to the sun or the stars).

>  Or time could be defined with the top 32 bits being ...

Of course it would be defined as a private type.

Re: Ada Calendar oddity <was Re: C date package>

[Charles Hixson]

Thanks for the reply.  Some responses follow (interspersed as appropriate).
Geoff Bull wrote:

> Charles Hixson wrote:
> >
> > It seems to me that it is a mistake to include seconds, much less any smaller
> > unit, in the calendar date.
>
> Astronomers and real time programers, e.g., might not agree
> with you. Although, of course, the latter group are catered
> for with Ada.Real_Time.
>
> >  I'm not sure that minutes is justified, but if
>
> Depends on what requirement you are trying to meet.

I was assuming a split between the Calendar class and the Time class.  Clearly if
one is building a DateTime class then minutes *MUST* be included.

> > one uses a 64 bit number then it wouldn't seem to cause any problems.
>
> Elsewhere it has already been stated that no more than 32 bits
> is essential (I have no opinion on this0.

But the 64 bit chips are starting to become more common.  How many bits is
essential depends on what one is trying to do (and the degree of precision).  By
some measures all that one needs is the floating point (32 bit!) # of years since,
say the founding of the city of Rome (i.e., A.U.C. dating).  But many wouldn't find
that convenient.  (And date/time formatting from that to the current calendar would
be a real nuisance!)

> > Perhaps Calendar and Time could be two separate packages, each using a 64-bit
> > number as their base, one based on days and the other based on
> > ?nano?-seconds.
>
> This is perhaps not a bad idea, because seconds and days are
> different concepts, one being a fixed period of time, the other
> being the variable amount of time for one rotation of the earth
> (either wrt to the sun or the stars).

I was thinking of days as being solar, and of seconds as being determined by atomic
clocks, but this probably doesn't signify.

> >  Or time could be defined with the top 32 bits being ...
>
> Of course it would be defined as a private type.

Well, yes.  But the implementor would need to be able to share information between
the Date and Time packages.  Of course, I may be making things more complex than
necessary.  I don't know how many bits of precision a 64 bit float would have, but
suppose one measured the number of days since 01/01/1904 (in honor of the Macintosh
[I think that's the right date!]).  To what precision could 12:01:03.14159 of
3000/01/31 be represented?  Of course, if this course is chosen, then one will need
to figure out what to do when a "leap second" is announced.  I was trying to skip
out of that problem.  Otherwise a sufficiently precise floating point number would
do all that one needed  (except for nicely formatted I/O).

The remaining problem would be how to specify the degree of accuracy to which the
time was known.  Consider "early in the morning of July 30 this year" or "sometime
in the late summer, of 4 BC" or "around 200,000 years ago".  These are all times,
specified to varying degrees of accuracy.

A slightly different kind of problem is "early in the spring, about a decade ago"
where the time of year is specified vaguely, but which year, itself, is not
specified.  This probably won't be handleable by any reasonable time class, but
needs consideration (as a representative of a class of problems).

Re: Ada Calendar oddity <was Re: C date package>

[Geoff Bull]

Charles Hixson wrote:
> But the 64 bit chips are starting to become more common.

You would probably want to have Extended_Calendar in an optional
annex, e.g. information systems. 
The RM only requires 16 bit ints, 24 bit fixed and single
precision floats (32 bit). I can't see people being too enthused
about forcing these limits up to 64 bit just to make date/time
more useful.

> I was thinking of days as being solar, and of seconds as being determined by atomic
> clocks, but this probably doesn't signify.

Atomic clocks are convenient because you can get TAI and UTC 
(they differ only by leap seconds) from GPS (including leap
second broadcasts). It is reasonable to assume that 
*most* implementations can relate local time to UTC
by a time zone offset.

> I don't know how many bits of precision a 64 bit float would have, 

3.5.7 (15) If Long_Float is predefined for an implementation, then
           its requested decimal precision shall be at least 11. 

> suppose one measured the number of days since 01/01/1904 (in honor of the Macintosh
> [I think that's the right date!]).

Why can't we just use the epoch for TAI?


> A slightly different kind of problem is "early in the spring, about a decade ago"
> where the time of year is specified vaguely, but which year, itself, is not
> specified. 

I saw a name for this time system somewhere.
The example was if you referred to the "'50s" you mean the period
1946 to 1954. The name of this system escapes me, but it is
a sufficiently fuzzy concept to be of no use for defining a
Calendar package.

Re: Ada Calendar oddity <was Re: C date package>

[Robert I. Eachus]

Robert A Duff wrote:
  
> The reason for the range 1901..2099 is that leap year calculations are
> simpler (and more efficient) in this range -- in this range, all years
> divisible by 4 are leap years (including 2000).  1900 and 2100 are not
> leap years.
 
   True, but that was the reason it was that way in Ada 83, when
avoiding the Y2K bug was a big deal.   Incidently, note that even in
that range there are countries that switched from the Julian to the
Gregorian calendar, so dates in early 1900's have to be taken with a
grain of salt.

   There was some discussion of changing the range for the year subtype
in
Ada 95, but it was felt to be unnecessary.  However, several changes in
the details were made so that Ada.Calendar.Time does not have an imposed
limit.
This was felt to be a minor upwardly compatible change, while forcing
existing compilers to change the underlying types to support some fixed
wider range would have imposed much more work.  This allows a Split
procedure (probably a in child package of Calendar) to be provided by an
implementation which supports a wider range of years.  Note also that it
would be nice to have child packages for other calendars, such as
Chinese,
Japanese, Jewish, and Muslim.

   I have done some work on how to provide such packages, but there are
serious problems of definition if you try to extend the date ranges
significantly.  It doesn't make much sense to take Gregorian dates back
before the 16th century, but the Julian calendar needs to carefully deal
with the lack of a year zero, and there have been several calendar
"reforms" which moved things around.  It is nice to be able to use the
same date as someone living in that era would have--but it is not a very
easy job.  In some cases there are suspected mis-correlations of
hundreds of years.

   By Ada0X or Ada1Y or whatever, there should be a much wider agreement
on  how the Ada.Calendar.Year subtype should be redefined, and maybe on
a rich set of subpackages to deal with other calendars.

Re: Ada Calendar oddity <was Re: C date package>

[Geoff Bull]

"Robert I. Eachus" wrote:
> 
> Robert A Duff wrote:
> 
> > The reason for the range 1901..2099 is that leap year calculations are
> > simpler (and more efficient) in this range -- in this range, all years
> > divisible by 4 are leap years (including 2000).  1900 and 2100 are not
> > leap years.
> 
>    True, but that was the reason it was that way in Ada 83, when
> avoiding the Y2K bug was a big deal. 

It was that kind of narrow (focussed on one problem) thinking
that led to the y2k bug!

Re: Ada Calendar oddity <was Re: C date package>

[Robert I. Eachus]

Geoff Bull wrote:
 
> It was that kind of narrow (focussed on one problem) thinking
> that led to the y2k bug!

   That definitely was not the case.  The fact that Year had a
constraint,
and the range of that constraint were both discussed--at length during
the standardization process.  The "Ada Doom Date" of December 31, 2099
was well known, with the realization that it would need to be fixed in a
subsequent version of the standard.  I don't know of anyone who has had
problems due to the 2099 limit, but there are several cases where the
1901 limit made Calendar.Time an unsuitable choice for representing
birthdates.

   During the Ada 9X revision, this issue was revisited, and the doom
date, as such, wasl removed.  An implementation can provide a
Calendar.Time type with a range significantly larger than two hundred
years and not have to make an explicit check for the doom date in the
arithmetic operators.  This change is found in RM 9.6(26).

   As I said in the previous post, I expect that the Year_Number subtype
will be extended in a future version of the standard.  (Changing the
range
for Year_Number would require a different representation for variables
of type Calendar.Time.  This is simething that needs to be done slowly,
and with plenty of warning to the compiler vendors.)  On the other hand,
a new Long_Time type would cause fewer upward compatibility problems.
;-)

Re: Ada Calendar oddity <was Re: C date package>

[Robert Dewar]

In article <3924D3FF.11D8C99A@earthlink.net>,
  "Robert I. Eachus" <rieachus@earthlink.net> wrote:
(Changing the
> range
> for Year_Number would require a different representation for
variables
> of type Calendar.Time.  This is simething that needs to be
done slowly,
> and with plenty of warning to the compiler vendors.)  On the
other hand,
> a new Long_Time type would cause fewer upward compatibility
problems.


What really *is* the situation with Ada 95 compilers. Certainly
in GNAT we chose a representation for Calendar.Time that can
accomodate very wide ranges of times and dates (Calendar.Time
is kept in units of nanoseconds stored in a signed 64 bit value
which represents very wide time ranges -- tens of thousands of
years at least).

It certainly is the case that representations of Calendar.Time
are the worrisome thing here (think for example of such values
written on files). A compiler that has chosen a narrow range
representation for this type has, in my view, made a significant
mistake which will cause nasty compatibility problems later,
but I don't know specifically that any compilers have made
this choice.

Anyone know what other Ada 95 compilers do?

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Calendar oddity <was Re: C date package>

[Robert Dewar]

In article <3924B35E.DC0C9CDF@acenet.com.au>,
  Geoff Bull <gbull@acenet.com.au> wrote:
> It was that kind of narrow (focussed on one problem) thinking
> that led to the y2k bug!

No, that's a mis-characterization. The Y2K bug was a product
of two unrelated phenomena:

1. Legacy code had a life time much longer than expected.

2. COBOL has very poor data abstraction capabilities, so
the problem could not be solved in the obvious manner, even
for well written code.


In the case of Ada, it is arguable whether todays legacy code
will last a hundred years in unchanged form.

In any case, well written code will simply not be dependent
on the range in any case, so changing the range will have no
effect on existing code. If anyone was interested for example,
it would be trivial to provide a version of Calendar for GNAT
that did not have this limit (it requires a couple of
declarations to be changed, and one simple test added to the
leap year circuit).




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Calendar oddity <was Re: C date package>

[Tarjei Tj�stheim Jensen]

Geoff Bull wrote:
> Maybe, but I can't use Ada.Calendar to represent dates more than
>  ~ +/- 100 years from today's date.
> It is beyond me why I need to create my own date package if I want to
> do more than look at today's date

To me it look like you are trying to use the calendar package for
something that it was not intended to do. Perhaps the name calendar is
wrong?

If you want to handle dates and times outside internal Ada scheduling, I
think you are supposed to create your own stuff.


Greetings,

Re: Ada Calendar oddity <was Re: C date package>

[Reinert Korsnes]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

In article <39298C83.7794DDB8@online.no>,
 "Tarjei Tj�stheim Jensen" <tarjei@online.no> writes:
|> Geoff Bull wrote:
|> > Maybe, but I can't use Ada.Calendar to represent dates more than
|> >  ~ +/- 100 years from today's date.
|> > It is beyond me why I need to create my own date package if I want to
|> > do more than look at today's date
|> 
|> To me it look like you are trying to use the calendar package for
|> something that it was not intended to do. Perhaps the name calendar is
|> wrong?
|> 
|> If you want to handle dates and times outside internal Ada scheduling, I
|> think you are supposed to create your own stuff.

But I love Ada.Calendar.  So elegant.  I use it under gnat and
calsulate times/durations over 10-20 years.... (when treating environment 
data).    But the conclusion is that I then do something really dirty ?   

reinert


|> 
|> 
|> Greetings,

-- 
Norwegian Polar Institute
Polar Environment Center
N-9296 Tromso
Norway
Fax: +47 77750501

http://geophys.npolar.no/~reinert/personal.html

Re: Ada Calendar oddity <was Re: C date package>

[Tarjei Tj�stheim Jensen]

Reinert Korsnes wrote:
> But I love Ada.Calendar.  So elegant.  I use it under gnat and
> calsulate times/durations over 10-20 years.... (when treating environment
> data).    But the conclusion is that I then do something really dirty ?

Not if you are using it for internal calculations, are aware of its
limitations and do not store any of it externally for others to use.

The moment you store it in an external file it is time to make sure you
are storing something that is portable.


Greetings,

Re: Ada Calendar oddity <was Re: C date package>

[Robert I. Eachus]

Geoff Bull wrote:
 
> Maybe, but I can't use Ada.Calendar to represent dates more than
>  ~ +/- 100 years from today's date.
> It is beyond me why I need to create my own date package if I want to
> do more than look at today's date

   First of all, using Time_Of, Split, and Year for dates in the early
20th century gets increasingly iffy, since conversions from the Julian
to the Gregorian calendar occurred at different times around the world. 
The   hard problem is to provide meaningful conversions of values of
Calendar.Time to Gregorian dates and vice-versa.  Not only is there a
programming programming, but of converting "old" dates correctly is not
easy.  I can fairly easily whip up a child package containing versions
of Split and Time_Of with an extra parameter (Julian or Gregorian), and
leave it up to the user to figure out when to use what, but that alone
is not enough.  Which is the first day of the year?  Julius Caesar
agreed reluctantly to January 1 instead of the Ides of March, but even
in colonial America, some people used March 20th or other spring
solstice dates.

   A more interesting version date package would have a location
parameter, and embed the different date rules for various locales. 
(Sweden is particularly messy.)  Just specialing to the country is not
enough, the area that is now the United States had five different
calendar conversions,  actually six since you have to count the French
Revolutionary calendar.

   Also as you go back in time beyond the establishment of the Julian
calendar, there are anomalies in the Julian calendar.  Everyone knows
that there was no year zero, but Ceaser Agustus also messed up the
length of the months at about that time. And Julius began the new
calendar with two odd length months.

   Projecting into the future is even more difficult.  When will there
next be a change in the calendar?  The length of the day is changing due
to the tidal influence of the moon, and in any case the Gregorian
calendar is drifting anyway.  Will 3000 be a leap year?  Or is 4000 a
better choice? It might be reasonable to decide that soon, but will the
Gregorian calendar even be in use a thousand years from now?  A few
years back, the so called World Calendar, with two intercalciary days
was proposed so that holidays would occur on the same day of the week
every year.  (In the US, we seem to have used a different method of
accomplishing that.)  The Chinese and Islamic calendars are still in
widespread use, and who knows what new calendars will be proposed.  (The
Hebrew calendar is still used as well, but mostly for religous
purposes.  Every bill passed by the US Congress has a date since July
4th 1776, but only a few people pay attention now.  Early on for the
United States, it was important to do that, since not everyone was using
the same calendar.)

Re: Ada Calendar oddity <was Re: C date package>

[Tarjei Tj�stheim Jensen]

Preben Randhol wrote:
> An example: If I were to make a program for issuing drivers licenses
> here in Norway there would be a problem. Well not immediately but in
> only 18 years.
> 
> The reason is that driver's licenses expires as you get 100 years old. So
> mine expires in 2073.
> 
> If one wanted to use the Year type in Ada.Calendar for birthday and
> expiration date, one would get an constraint error when one issued
> drivers licences for these born this year. Wouldn't one?
> 
> I may have missed some thing important when I speedily "read" the
> Ada.Calendar, but this seems a bit odd to me (the upper limit that is).


That would be a wrong use of the type. The drivers license "problem" is
a database issue. You should not use something that is internal to Ada
in that context.


Greetings,

Re: Ada Calendar oddity <was Re: C date package>

[Charles Hixson]

"Tarjei Tj�stheim Jensen" wrote:

> Preben Randhol wrote:
> --snip
> > The reason is that driver's licenses expires as you get 100 years old. So
> > mine expires in 2073.
> >
> > If one wanted to use the Year type in Ada.Calendar for birthday and
> > expiration date, one would get an constraint error when one issued
> > drivers licences for these born this year. Wouldn't one?
> --snip.
>
> That would be a wrong use of the type. The drivers license "problem" is
> a database issue. You should not use something that is internal to Ada
> in that context.
>
> Greetings,

This seems to imply the assumption that the database would not be implemented
in Ada.  For some purposes this is reasonable (SQL is frequently nice, and has
already been done).  For other purposes it doesn't seem reasonable at all.  If
I don't need a full relational database, why should I need to drag one along?

Re: Ada Calendar oddity <was Re: C date package>

[Tarjei Tj�stheim Jensen]

Charles Hixson wrote:
>
> This seems to imply the assumption that the database would not be implemented
> in Ada.  For some purposes this is reasonable (SQL is frequently nice, and has
> already been done).  For other purposes it doesn't seem reasonable at all.  If
> I don't need a full relational database, why should I need to drag one along?

1. Because a full relational database is VERY nice to have and causes
few surprises. It is not a matter of not needing one. It is a matter of
not being able to use one.

2. The Ada type is simply not apropriate in this context. This is a
typical DP application. When doing DP stuff, do it the way DP stuff
should be done.

3. When implementing Ada support for the database one makes sure that
one includes the proper date/time stuff into the support library.


Greetings,

Re: Ada Calendar oddity <was Re: C date package>

[Charles Hixson]

"Tarjei Tj�stheim Jensen" wrote:

> Charles Hixson wrote:
> >
> > This seems to imply the assumption that the database would not be implemented
> > in Ada.  For some purposes this is reasonable (SQL is frequently nice, and has
> > already been done).  For other purposes it doesn't seem reasonable at all.  If
> > I don't need a full relational database, why should I need to drag one along?
>
> 1. Because a full relational database is VERY nice to have and causes
> few surprises. It is not a matter of not needing one. It is a matter of
> not being able to use one.\

It's certainly nice for a programmer to have the choice of using a relational
database, but for many applications it is extreme overkill, and causes the
applications to bloat so much that more expensive hardware is required to run them.
Sometimes one even wants to store the data in a flat file, load it all into RAM at
program start, and then (maybe) write out any changes at the end.  Relational is
only one option.

> 2. The Ada type is simply not apropriate in this context. This is a
> typical DP application. When doing DP stuff, do it the way DP stuff
> should be done.

If you are talking about the predefined types, then sometimes yes, sometimes no.
But one can always choose to define a type appropriate to the problem at hand.
"Should" is, by definition, correct.  But I doubt that we are in agreement as to
what "the way DP stuff should be done" means.  I see this as very context dependent.

> 3. When implementing Ada support for the database one makes sure that
> one includes the proper date/time stuff into the support library.

If one is using a preexisting private library, then this is correct.  But different
applications have very different needs.  Sometimes the most important thing is that
they be cheap, portable, and small.  Basic ISAM will let one handle many things with
a lot less weight than a full RDBMS.  And a stand-alone executable file is sometimes
what one really wants.

> Greetings,

Re: Ada Calendar oddity <was Re: C date package>

[Tarjei Tj�stheim Jensen]

Charles Hixson wrote:
> It's certainly nice for a programmer to have the choice of using a relational
> database, but for many applications it is extreme overkill, and causes the
> applications to bloat so much that more expensive hardware is required to run them.
> Sometimes one even wants to store the data in a flat file, load it all into RAM at
> program start, and then (maybe) write out any changes at the end.  Relational is
> only one option.

It is usually the other way around. One finds that the use of a database
make it possible to get more from your data. And the various report
tools gives you a lot of interesting possibilities which you don't
normally get if you do everything by yourself. That is why databases are
popular. If the database requires a hot iron to run it, it just means
that you either have done a bad programming job or you underestimated
the size of the project.

In fact a lot of people are spending time moving a lot of flat files to
databases in order to get database benefits.

> If you are talking about the predefined types, then sometimes yes, sometimes no.
> But one can always choose to define a type appropriate to the problem at hand.
> "Should" is, by definition, correct.  But I doubt that we are in agreement as to
> what "the way DP stuff should be done" means.  I see this as very context dependent.

Possibly. I'm quite convinced that a DP person would have no problem
understanding what I meant.

> > 3. When implementing Ada support for the database one makes sure that
> > one includes the proper date/time stuff into the support library.
> 
> If one is using a preexisting private library, then this is correct.  But different
> applications have very different needs.  Sometimes the most important thing is that
> they be cheap, portable, and small.  Basic ISAM will let one handle many things with
> a lot less weight than a full RDBMS.  And a stand-alone executable file is sometimes
> what one really wants.

Basic ISAM will go wrong in a lot more ways and more times than your
ordinary commercial grade database. In this context mysql and its like
are not a commercial grade database. Postgresql is.


Greetings,

Re: Ada Calendar oddity <was Re: C date package>

[Geoff Bull]

"Tarjei Tj�stheim Jensen" wrote:
> 
> > If one wanted to use the Year type in Ada.Calendar for birthday and
> > expiration date, one would get an constraint error when one issued
> > drivers licences for these born this year. Wouldn't one?

> That would be a wrong use of the type. The drivers license "problem" is
> a database issue. You should not use something that is internal to Ada
> in that context.

So when you read a date from the database, what type should you use?
If you avoid using Ada.Calendar how do you compare the database time
with the today's date, e.g.?

Re: Ada Calendar oddity <was Re: C date package>

[Gautier]

Geoff Bull:

> So when you read a date from the database, what type should you use?
> If you avoid using Ada.Calendar how do you compare the database time
> with the today's date, e.g.?

Simple ;-) : you make a package Long_Calendar with all operators
and also conversions from and to Ada.Calendar. It could use the
Julian date. NB: the problem occurs also with data prior to 1901
- it exists, e.g. for environmental statistics with precise dates !
Check Deja News for a hot debate that happened some year(s) ago on this
topic...
_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: Ada Calendar oddity <was Re: C date package>

[Geoff Bull]

Gautier wrote:
> 
> Geoff Bull:
> 
> > So when you read a date from the database, what type should you use?
> > If you avoid using Ada.Calendar how do you compare the database time
> > with the today's date, e.g.?
> 
> Simple ;-) : you make a package Long_Calendar with all operators
> and also conversions from and to Ada.Calendar. 

Sure, but you only have to do this because of the inadequacy
of Ada.Calendat, not because it is funadanmentally bad practice
to use the standard Ada libraries (that is how I interpreted
what "Tarjei Tj�stheim Jensen" wrote - in restrospect, I realise
he meant that is was incorrect to use Ada.Calendar in this context
because Ada.Calendar was incapable of doing the job at hand).

Re: Ada Calendar oddity <was Re: C date package>

[Gautier]

Geoff Bull:

> > Simple ;-) : you make a package Long_Calendar with all operators
> > and also conversions from and to Ada.Calendar.

> Sure, but you only have to do this because of the inadequacy
> of Ada.Calendar, not because it is fundamentally bad practice
> to use the standard Ada libraries.

I'm also from the opinion that the range for years in Ada.Calendar
is really too narrow - hence the smiley... Maybe widen this range
for Ada 0X ?...

_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: Ada Calendar oddity <was Re: C date package>

[Al Christians]

I note that your posting shows up on my browser with the date using 25 
bytes in the header.  If the internet can use such inefficient formats,
there is not much excuse for serious programmers sacrificing range and 
scale by shaving bits.  For example, using only 16 bytes, eg 128 bits,
eg representing seconds with 64 bits to the left of the binary point and 
64 to the right,  I think we get a range about a thousand times the age
of the universe and a precision shorter than the time it takes anything
to happen, except that if I've made a mistake here, someone will take
less than 2^(-64) seconds to point it out.    Not many applications 
would need more range or scale than that, would they?


Al

Gautier wrote:
> 
> 
> I'm also from the opinion that the range for years in Ada.Calendar
> is really too narrow - hence the smiley... Maybe widen this range
> for Ada 0X ?...
>

Re: C date package

[Ken Garlington]

Just out of curiosity, I was going to ask why your week started on Monday:

>    type Day_Name is
>      (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday,
> Sunday);

>    function Week_In_Year (Date : Ada.Calendar.Time) return
> Week_In_Year_Number;
>    --  Returns the week number in the year with Monday as first
> day of week

and then I noticed the comments in GNAT.Calendar.Time_IO:

>  It follows the GNU Date
> specification. Here are the recognized directives :
>    --          Date fields:
>    --
>    --          %a   locale's abbreviated weekday name (Sun..Sat)
>    --          %A   locale's    full   weekday   name,
> variable   length
>    --                  (Sunday..Saturday)
>    --          %U   week number  of year with  Sunday as first
> day  of week
>    --                  (00..53)
>    --          %w   day of week (0..6) with 0 corresponding to
> Sunday
>    --          %W   week number  of year with  Monday as first
> day  of week

which implies that, although it's acceptable in GNU to start counting weeks
on either Sunday or Monday, the first (zero'th) day of the week is always
Sunday? Is this right?

Re: C date package

[Geoff Bull]

Ken Garlington wrote:
> 
> Just out of curiosity, I was going to ask why your week started on Monday:
> 
> >    type Day_Name is
> >      (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday,
> > Sunday);
> 
> >    function Week_In_Year (Date : Ada.Calendar.Time) return
> > Week_In_Year_Number;
> >    --  Returns the week number in the year with Monday as first
> > day of week

> 
> which implies that, although it's acceptable in GNU to start counting weeks
> on either Sunday or Monday, the first (zero'th) day of the week is always
> Sunday? Is this right?

ISO8601 defines Monday as the first day of the week when it
comes to numbering weeks within years.
The first week of the year is the week that contains the first Thursday.
ISO8601 also says that Monday is numbered as 1 and Sunday is numbered as 7.


Right depends on what "standard" you are applying.

Cheers
Geoff

Re: C date package

[Geoff Bull]

Robert Dewar wrote:
> 
> By the way, have a look at the package GNAT.Calendar in GNAT
> 3.13 which fills in some of the gaps. In fact let me post the
> spec here. There is also a GNAT.Calendar.Time_IO that allows
> flexible output of times

Cool!
Fortuneately I am using 3.12p so I don't have to admit to
failing to look in the library. :-)