Re: calander package

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

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.
>
>
>