calander package

calander package

[arcele]

Hi, i'm trying to use to calender package to put the current date into a
string or integer.  I understand taht using calandar.split will split the
days, hours, etc. but how can i use the package to put the date in the form
of    yymmdd  ???? thanks in advance for any help - ryan

Re: calander package

[Marin David Condic]

What you'll have to do is take the individual pieces of the date/time and
convert them to appropriate strings. There are no subprograms defined in
Calendar to automatically give you the date/time as string values.

If you want some help with this, check out my web page:
http://www.mcondic.com/ and look for the "Ada Programming" subpage. There's
a collection of code there under the title "Utilities" in which you'll find
a package that formats dates/times into various styles.

Hope this helps!

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/



"arcele" <unhuh@hotmail.com> wrote in message
news:98jo6d$vu4$1@slb3.atl.mindspring.net...
> Hi, i'm trying to use to calender package to put the current date into a
> string or integer.  I understand taht using calandar.split will split the
> days, hours, etc. but how can i use the package to put the date in the
form
> of    yymmdd  ???? thanks in advance for any help - ryan
>
>

Re: calander package

[Ted Dennison]

In article <98jo6d$vu4$1@slb3.atl.mindspring.net>, arcele says...
>Hi, i'm trying to use to calender package to put the current date into a
>string or integer.  I understand taht using calandar.split will split the
>days, hours, etc. but how can i use the package to put the date in the form
>of    yymmdd  ???? thanks in advance for any help - ryan

Is this a homework assignment? I could point you to some code that does exactly
that, but that would be pretty backhanded help if the point is for you to
*learn* how to do this.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: calander package

[Marin David Condic]

If it is homework, it is a pretty trivial assignment. Considering that many
languages come with existing string-formatted dates/times &/or subprograms
to get you there. Its more a matter of "What stuff do I call to get this to
happen" in most cases. Ada's Calendar package probably should have had this
in it somewhere, but its no biggie to roll-your-own. (Unless you want to get
really fancy! :-)

Seems to me that "arcele" did the hard part in finding Calendar and how to
call things in it. The rest is probably fair game for an inquiry or
"software reuse", even if it is homework.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:Rmrr6.2912$54.3153@www.newsranger.com...
> Is this a homework assignment? I could point you to some code that does
exactly
> that, but that would be pretty backhanded help if the point is for you to
> *learn* how to do this.

Re: calander package

[Ted Dennison]

In article <98lis0$56j$1@nh.pace.co.uk>, Marin David Condic says...
>
>If it is homework, it is a pretty trivial assignment. Considering that many
>languages come with existing string-formatted dates/times &/or subprograms
>to get you there. Its more a matter of "What stuff do I call to get this to
>happen" in most cases. Ada's Calendar package probably should have had this
>in it somewhere, but its no biggie to roll-your-own. (Unless you want to get
>really fancy! :-)
>
>Seems to me that "arcele" did the hard part in finding Calendar and how to
>call things in it. The rest is probably fair game for an inquiry or
>"software reuse", even if it is homework.

Well, with that caveat, I'll mention that the 2.0 release of the SETI@Home
service just happens to have a routine in it that does exactly that (for
date/time-stamping log entries). It'd probably be just as easy for most folks to
write their own, though.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: calander package

[Marin David Condic]

Near trivial if all you want is MM/DD/YY or something similar. Still, it
seems a shame that Ada.Calendar didn't provide one or more functions to
return the date/time as a string - just because it is frequently needed and
getting it from the language environment would imply a certain amount of
consistency.

I've built my own to generate the date/time in a whole variety of formats
because on any number of occasions you might need it different ways. Maybe I
should revisit this code with the goal of consolidating it down to fewer
routines with more options? A dozen or so formats suggests an enumeral and
the rest would be some flavor of "What character(s) do you like for
separators?" and "Did you want the current time or are you going to give me
a time of your own?"

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:%%tr6.2979$54.3285@www.newsranger.com...
> In article <98lis0$56j$1@nh.pace.co.uk>, Marin David Condic says...
> Well, with that caveat, I'll mention that the 2.0 release of the SETI@Home
> service just happens to have a routine in it that does exactly that (for
> date/time-stamping log entries). It'd probably be just as easy for most
folks to
> write their own, though.
>

Re: calander package

[Randy Brukardt]

Marin David Condic wrote in message <98ltmj$90q$1@nh.pace.co.uk>...

>I've built my own to generate the date/time in a whole variety of
formats
>because on any number of occasions you might need it different ways.
Maybe I
>should revisit this code with the goal of consolidating it down to
fewer
>routines with more options? A dozen or so formats suggests an enumeral
and
>the rest would be some flavor of "What character(s) do you like for
>separators?" and "Did you want the current time or are you going to
give me
>a time of your own?"

I've done this dozens of times, too. So, when the problem came up with
the Smplsrvr, we went ahead and added a package of operations to Claw.
The Claw.Time package really doesn't depend on Claw itself (nor on
Windows), so it could be used separately. It's in the Claw Introductory
version, which is available for free non-commerical use at
www.rrsoftware.com.

I was thinking about proposing something on this line to the ARG for
standardization, but it unclear that the ARG is interested in
(semi-)standardizing these sorts of packages. (It seems to run about
50-50 within the membership as to whether time should be spent on it.
The objections mostly are that there are more important things to work
on.)

                Randy Brukardt.

Re: calander package

[Marin David Condic]

Well, a while ago there was an attempt to have a Standard Components working
group come up with a bunch of utility stuff like data structures, etc. For
whatever reasons it sort of collapsed. Maybe nobody had enough time to "own"
the group?

Anyway, I think the way things like date tools could make it into the Ada
language as a part of the standard would be through a process similar to
this. If there were a group of die-hard Ada fans who developed some useful
collection of general-purpose code (dates, math functions, data structures,
etc.) and it gained some level of acceptance as a pseudo-standard, then it
wouldn't be that big a deal to extend compilers to include it. (Well, O.K.
If it was part of the standard, someone would feel honor-bound to require it
be tested & that could end up looking like work!) This is certainly how a
lot of functions have made their way into C as part of the standard or a de
facto standard. Everyone just glommed onto the software and included it in
their compiler distribution within the search path.

AFAIK, it isn't required that a compiler allow you to create child packages
of standard Ada packages and this has bitten me in the past. (Not legal to
make "Ada.Numerics.My_Cool_Stuff"?) Hence it isn't likely that Calendar
itself can be extended except by the compiler writers - and you're back to
"more pressing things to do". But maybe there's some way to allow for this
kind of extension in a semi-standard way that encourages the development of
useful packages that might get adopted by the compiler vendors. For example,
if there was an "Ada.Extras" package (pick whatever name you like) that was
specified by the standard as the "standard" way of providing "non-standard"
packages as children, this might help breed non-standard extensions that
eventually become standard extensions? Hmmmm? If you use them, you know
you're not guaranteed portable - just like the optional appendices - but it
becomes the place to create utility code that might get adopted by one or
more compiler vendors?

GNAT provides some useful extensions in a similar way, but what other
compiler vendor is going to want to have GNAT.Something as part of their
product? Bad publicity. However Win32Ada seems to have been adopted as a
semi-standard, so it can be done - just not if it looks like someone else is
going to get the credit or ownership. It would be nice to see some set of
utilities migrate into Ada in some manner that gave one confidence in using
them without requiring additions to the ARM.....

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:nAwr6.4569$7e6.1762378@homer.alpha.net...
>
> I've done this dozens of times, too. So, when the problem came up with
> the Smplsrvr, we went ahead and added a package of operations to Claw.
> The Claw.Time package really doesn't depend on Claw itself (nor on
> Windows), so it could be used separately. It's in the Claw Introductory
> version, which is available for free non-commerical use at
> www.rrsoftware.com.
>
> I was thinking about proposing something on this line to the ARG for
> standardization, but it unclear that the ARG is interested in
> (semi-)standardizing these sorts of packages. (It seems to run about
> 50-50 within the membership as to whether time should be spent on it.
> The objections mostly are that there are more important things to work
> on.)
>

Re: calander package

[tmoran]

>return the date/time as a string - just because it is frequently needed and
>getting it from the language environment would imply a certain amount of
>consistency.
  It appears everyone has their own handy, but slightly different from
everyone else, package. :(
  I'll offer package Claw.Time at www.rrsoftware.com

Re: calander package

[Vincent Marciante]

Randy Brukardt wrote:
> 
> 
> I was thinking about proposing something on this line to the ARG for
> standardization, but it unclear that the ARG is interested in
> (semi-)standardizing these sorts of packages. (It seems to run about
> 50-50 within the membership as to whether time should be spent on it.
> The objections mostly are that there are more important things to work
> on.)
> 
>                 Randy Brukardt.

The original Booch.Calendar_Utilities could be considered.

http://www.adapower.com/original_booch/

Its spec follows.

Vinny


--    Original Booch Components (Ada 95 elaboration version)
-- Copyright (C) 2000 Grady Booch, provided WITHOUT ANY WARRANTY.
-- Further license details should appear at the end of this file.

with Calendar;
package Booch.Calendar_Utilities is
pragma Elaborate_Body;

    type Year        is new Calendar.Year_Number;
    type Month       is range 1 ..  12;
    type Day         is range 1 ..  31;
    type Hour        is range 0 ..  23;
    type Minute      is range 0 ..  59;
    type Second      is range 0 ..  59;
    type Millisecond is range 0 .. 999;

    type Time is
        record
            The_Year        : Year;
            The_Month       : Month;
            The_Day         : Day;
            The_Hour        : Hour;
            The_Minute      : Minute;
            The_Second      : Second;
            The_Millisecond : Millisecond;
        end record;

    type Interval is
        record
            Elapsed_Days         : Natural;
            Elapsed_Hours        : Hour;
            Elapsed_Minutes      : Minute;
            Elapsed_Seconds      : Second;
            Elapsed_Milliseconds : Millisecond;
        end record;

    type Year_Day    is range 1 .. 366;

    type Month_Name  is (January, February, March, April, May, June,
July, 
                         August, September, October, November,
December);
    type Day_Name    is (Monday, Tuesday, Wednesday, 
                         Thursday, Friday, Saturday, Sunday);

    type Period      is (Am, Pm);

    type Time_Format is (Full,            -- 01:21:06:30 PM
                         Military);       -- 13:21:06:30
    type Date_Format is (Full,            -- FEBRUARY 27, 1955
                         Month_Day_Year); -- 02/27/55

    function Is_Leap_Year  (The_Year  : in Year)          return
Boolean;
    function Days_In       (The_Year  : in Year)          return
Year_Day;
    function Days_In       (The_Month : in Month; 
                            The_Year  : in Year)          return Day;
    function Month_Of      (The_Month : in Month)         return
Month_Name;
    function Month_Of      (The_Month : in Month_Name)    return Month;
    function Day_Of        (The_Year  : in Year; 
                            The_Day   : in Year_Day)      return
Day_Name;
    function Day_Of        (The_Time  : in Time)          return
Year_Day;
    function Time_Of       (The_Year  : in Year;  
                            The_Day   : in Year_Day)      return Time;
    function Period_Of     (The_Time  : in Time)          return Period;
    function Time_Of       (The_Time  : in Time)          return
Calendar.Time;
    function Time_Of       (The_Time  : in Calendar.Time) return Time;

    function Time_Image_Of (The_Time  : in Time; 
                            Time_Form : in Time_Format := Full) 
                                                          return String;
    function Date_Image_Of (The_Time  : in Time; 
                            Date_Form : in Date_Format := Full) 
                                                          return String;
    function Value_Of      (The_Date  : in String; 
                            The_Time  : in String; 
                            Date_Form : in Date_Format := Full; 
                            Time_Form : in Time_Format := Full) 
                                                          return Time;

    function Duration_Of (The_Interval : in Interval)     return
Duration;
    function Interval_Of (The_Duration : in Duration)     return
Interval;
    function Image_Of    (The_Interval : in Interval)     return String;
    function Value_Of    (The_Interval : in String)       return
Interval;

    Lexical_Error : exception;

end Booch.Calendar_Utilities;

--        Original Booch Components (Ada 95 elaboration version)
--                               
-- Copyright (C) 2000 Grady Booch
--
-- This is free software; you can redistribute it and/or modify it under
-- terms of the GNU General Public License as published by the Free
Software
-- Foundation; either version 2, or (at your option) any later version.
-- This software is distributed in the hope that it will be useful, but 
-- WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY
-- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License
-- for more details. Free Software Foundation, 59 Temple Place - Suite
-- 330, Boston, MA 02111-1307, USA.
--
-- As a special exception, if other files instantiate generics from this
-- unit, or you link this unit with other files to produce an
executable,
-- this unit does not by itself cause the resulting executable to be
-- covered by the GNU General Public License. This exception does not
-- however invalidate any other reasons why the executable file might be
-- covered by the GNU General Public License.  
--
-- The book
_SOFTWARE_COMPONENTS_WITH_Ada__Structures,_Tools,_and_Subsystems_
-- ISBN 0-8053-0609-9 by Grady Booch, fully describes the design and
usage 
-- of this software.
--
-- The Ada 83 version of the components is the exact version described
in
-- the book mentioned above.  The Ada 95 elaboration version differs
only in
-- that each component unit is a child of a root package named "Booch"
and
-- each package declaration includes the most appropriate elaboration
control
-- pragma.  In addition, the Ada 95 child iteration version eliminates
the
-- distinct iterator and noniterator forms for components that had them
and
-- instead makes the associated "Iterate" procedures available as
children of
-- those components.  More enhanced versions may be produced in the
future.
--
-- The Original Booch Components are actively maintained and enhanced
-- by Vincent Marciante and Samuel T. Harris and may be found at the 
-- AdaPower web site (http://www.adapower.com) provided by David Botton.

Re: calander package

[Jeffrey Carter]

Ted Dennison wrote:
> 
> In article <98lis0$56j$1@nh.pace.co.uk>, Marin David Condic says...
> >
> >If it is homework, it is a pretty trivial assignment. Considering that many
> >languages come with existing string-formatted dates/times &/or subprograms
> >to get you there. Its more a matter of "What stuff do I call to get this to
> >happen" in most cases. Ada's Calendar package probably should have had this
> >in it somewhere, but its no biggie to roll-your-own. (Unless you want to get
> >really fancy! :-)
> >
> >Seems to me that "arcele" did the hard part in finding Calendar and how to
> >call things in it. The rest is probably fair game for an inquiry or
> >"software reuse", even if it is homework.
> 
> Well, with that caveat, I'll mention that the 2.0 release of the SETI@Home
> service just happens to have a routine in it that does exactly that (for
> date/time-stamping log entries). It'd probably be just as easy for most folks to
> write their own, though.

With the same caveat, I'll mention PragmARC.Date_Handler, part of the
PragmAda Reusable Components. See

http://home.earthlink.net/~jrcarter010/pragmarc.htm

or the mirror at www.adapower.com.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail

Re: calander package

[Pascal Obry]

"arcele" <unhuh@hotmail.com> writes:

> Hi, i'm trying to use to calender package to put the current date into a
> string or integer.  I understand taht using calandar.split will split the
> days, hours, etc. but how can i use the package to put the date in the form
> of    yymmdd  ???? thanks in advance for any help - ryan

In case you are using GNAT have a look at GNAT.Calendar and
GNAT.Calendar.Time_IO.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: calander package

[Mario Amado Alves]

Package Datetime provides conversion between date/time legible formats and
Ada Time values. It is an Adªlib package, category Miscelany:

  http://lexis.di.fct.unl.pt/ADaLIB/

| |,| | | |RuaFranciscoTaborda24RcD 2815-249CharnecaCaparica 351+939354005
|M|A|R|I|O|
|A|M|A|D|O|DepartmentoDeInformaticaFCT/UNL 2825-114 Caparica 351+212958536
|A|L|V|E|S|                                                  fax 212948541
| | | | | |                 maa@di.fct.unl.pt                FCT 212948300

Re: calander package

[Marin David Condic]

This might be a viable idea for a "semi-standard" add-on package to Ada.
However, one gripe: I think that the package ought to support Microseconds
since there are often times where this level of resolution is possible &
desirable. On systems where you don't have it, it just rounds up to whatever
resolution you do have. On that argument, one might even go so far as to ask
for representation of Nanoseconds, given that a 32 bit word could hold the
Nanoseconds in a Second. Except for specialized things, you're not likely to
get a clock resolution much better than that any time soon - otherwise I'd
ask for Attoseconds or something equally ridiculous! :-)

So perhaps a version of the package should be created that replaces
Milliseconds with Micro or Nanoseconds? (You definitely don't want to have
micro-within-milli. I've seen that done and it gets really confusing!)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Vincent Marciante" <marciant@li.net> wrote in message
news:3AAED192.1479@li.net...
> The original Booch.Calendar_Utilities could be considered.
>
> http://www.adapower.com/original_booch/
>
> Its spec follows.
>
<snip>
>     type Time is
>         record
>             The_Year        : Year;
>             The_Month       : Month;
>             The_Day         : Day;
>             The_Hour        : Hour;
>             The_Minute      : Minute;
>             The_Second      : Second;
>             The_Millisecond : Millisecond;
>         end record;

Re: calander package

[Marin David Condic]

That ought to be a clue to the powers-that-be in the Language Design
Business. If its something everyone ends up building - only with slight
variations - then maybe having a standard, language supplied (or at least
approved) version of it would be A Good Thing.

Same argument went around about math functions in Ada83. The argument
against having something like Ada.Numerics... was that a) it was easy enough
for people to extend Ada with packages on their own, b) it wasn't needed for
all systems everywhere, c) we've got more pressing problems to deal with
like getting Tasking to work at some rational speed. What happened was that
every compiler vendor ended up supplying their own Log and Trig functions in
their own way & nobody could write math related code that could count on
some sort of portable interface to the math routines.

Granted, time as strings, etc, is not as common as math functions, but its
still pretty common. What would be wrong with an appendix or some other
means of specifying "If you are going to have a Time-As-Strings package,
here's an agreed-upon spec to adhere to..."?

And since this issue is bound to come up with other utility code, perhaps
some thought could be given to a more general mechanism of adding utilities
to Ada in a semi-standard way? That is to say, maybe defining a root package
that can be extended with a utility environment that may or may not be
supplied by a vendor or user group could be a useful way of organically
growning de facto standard packages. If there was an agreed-upon
Ada.Utilities.... as the root and a handful of agreed-upon specs as a
starting point (Ada.Utilities.Timekeeping? Ada.Utilities.Whatever?) so that
extensions could be supplied & used in a conventional way, it might
encourage more development of this sort of thing.

MDC

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:pgzr6.29799$zV3.2243883@news1.frmt1.sfba.home.com...
>   It appears everyone has their own handy, but slightly different from
> everyone else, package. :(
>   I'll offer package Claw.Time at www.rrsoftware.com

Re: calander package

[Jeffrey Carter]

Vincent Marciante wrote:
> 
> The original Booch.Calendar_Utilities could be considered.
> ...
>     type Date_Format is (Full,            -- FEBRUARY 27, 1955
>                          Month_Day_Year); -- 02/27/55

Neither of these formats is acceptable for my use.

-- 
Jeff Carter
"Nobody expects the Spanish Inquisition!"
Monty Python's Flying Circus

Re: calander package

[Randy Brukardt]

Marin David Condic wrote in message <98o2b5$46t$1@nh.pace.co.uk>...
>That ought to be a clue to the powers-that-be in the Language Design
>Business. If its something everyone ends up building - only with slight
>variations - then maybe having a standard, language supplied (or at
least
>approved) version of it would be A Good Thing.


I don't think anyone argues that having something would be a good thing.

The problem is that everyone has a different idea of what it ought to
be. If you look at the various packages mentioned in this thread, you'll
discover that they all are very different. That would make it hard to
have agreement. (It is usually the case that the issues that everyone
understands are the ones that are the hardest to resolve -- because
everyone has an opinion.)

In addition, most of them have little or no documentation. And none of
them come close to the level of documentation required in a language
standard. The Ada 95 packages have plenty of problems caused by
omissions; we don't need a repeat of that with any new packages.

The problem is that most people are happy to do the fun part of defining
a spec. and maybe even writing a reference implementation, but hardly
anyone is willing to go through the work of a properly documented
proposal. The ARG wants proposals, not random good ideas. (We can
generate plenty of those without any help!)

                    Randy.

Re: calander package

[Marin David Condic]

You might look over the stuff in the Utilities code on my web page (search
for "date_tools" in the .chop file, IIRC.) I've got code there that delivers
a large number of different formats. I may even have written a test driver
for it - maybe. (Senility setting in again! :-) You may find one there you
like - or maybe you suggest a new one and when I get that elusive Round
Tuit, I might add it...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3AB00B6C.35FF41BC@acm.org...
> Vincent Marciante wrote:
> >
> > The original Booch.Calendar_Utilities could be considered.
> > ...
> >     type Date_Format is (Full,            -- FEBRUARY 27, 1955
> >                          Month_Day_Year); -- 02/27/55
>
> Neither of these formats is acceptable for my use.
>
> --
> Jeff Carter
> "Nobody expects the Spanish Inquisition!"
> Monty Python's Flying Circus

Re: calander package

[Marin David Condic]

I grok that. There's always debate about things like which format ought to
be the "standard" format - or if it should support multiple formats, etc.
Agreement is hard and, yes, most people don't want to devote the time needed
for a formal specification.

Many OS's  have a "standard" date format they use - perhaps that would be
sufficient? If there was a single function that had a time input parameter
and returned a string in some "implementation defined" format, that would at
least be a hook to some OS service that may be pretty common.

Note that somehow ANSI C succeeded in providing asctime as a function to
provide a string version of time. (Someone is now going to jump in here and
say "Well use Ada to bind to it!!!" :-) Maybe a similar definition could be
borrowed?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/



"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:84Vr6.4685$7e6.1798617@homer.alpha.net...
> I don't think anyone argues that having something would be a good thing.
>
> The problem is that everyone has a different idea of what it ought to
> be. If you look at the various packages mentioned in this thread, you'll
> discover that they all are very different. That would make it hard to
> have agreement. (It is usually the case that the issues that everyone
> understands are the ones that are the hardest to resolve -- because
> everyone has an opinion.)
>
> In addition, most of them have little or no documentation. And none of
> them come close to the level of documentation required in a language
> standard. The Ada 95 packages have plenty of problems caused by
> omissions; we don't need a repeat of that with any new packages.
>
> The problem is that most people are happy to do the fun part of defining
> a spec. and maybe even writing a reference implementation, but hardly
> anyone is willing to go through the work of a properly documented
> proposal. The ARG wants proposals, not random good ideas. (We can
> generate plenty of those without any help!)
>
>                     Randy.
>
>
>

Planned increment for package Datetime

[Mario Amado Alves]

Still a propos the date formats issue. Fresh news. Excerpt from
"http://lexis.di.fct.unl.pt/ADaLIB/datetime.htm":

"""
Planned increment: extension to other formats

An enumeration listing all implemented formats:

  type Formats is (Default_Format, ...);

where Default_Format is the 27-characters adjustable format descibed above.
Functions with a corresponding additional optional argument:

  function Value(
    Datetime: in String;
    Format: in Formats := Default_Format)
    return Time;

  function Image(
    Time_Value: in Time
    Format: in Formats := Default_Format)
    return String;

Function bodies incremented accordingly. Use a case construct on Format.
Because the Format parameter is optional, the increment is backward
compatible.
"""

Effecting this increment is left as an training exercise to the students
who originally sought a "calander" (sic) package ;-)

| |,| | | |RuaFranciscoTaborda24RcD 2815-249CharnecaCaparica 351+939354005
|M|A|R|I|O|
|A|M|A|D|O|DepartmentoDeInformaticaFCT/UNL 2825-114 Caparica 351+212958536
|A|L|V|E|S|                                                  fax 212948541
| | | | | |                 maa@di.fct.unl.pt                FCT 212948300

Re: calander package

[Robert A Duff]

Jeffrey Carter <jrcarter@acm.org> writes:

> Vincent Marciante wrote:
> > 
> > The original Booch.Calendar_Utilities could be considered.
> > ...
> >     type Date_Format is (Full,            -- FEBRUARY 27, 1955
> >                          Month_Day_Year); -- 02/27/55
> 
> Neither of these formats is acceptable for my use.

I kind of like the method used in the Scribe text formatting language.
The user can define whatever format they like.  The method is to write
a certain example date in the format you like, something like:

    @DefineDateFormat{Wednesday -- Feb. 23, 55}

The system determines the general rule from that example,
and formats all dates accordingly.

I believe the example date is Brian Reid's birthdate.
(Brian Reid designed Scribe as his PhD thesis.)

- Bob