Re: calander package - Proposal for dates

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

Well, the problem is this: If you *don't* want to limit things to some fixed
set of formats, you're only going to invent some programming language for
"rolling your own". Maybe it would be a tad easier than simply using Ada
features, but ultimately, it will be some kind of programming task. At that
point, you have to ask: "Why not just rely on Ada to do it?"

I've coded a bunch of date/time-to-string formatting routines with Ada and
they are generally pretty small. If you were to provide some flavor of
'Image for date/time pieces, it might make things a bit more efficient, but
I don't know that it would be big enough to make much difference. (You can
already get the 'Image of the pieces after you convert the time to numeric
pieces. Seems like at best you can eliminate one step.)

OTOH, if the package Calendar (or some child) had some Image functions that
gave you back strings of the form "January" and "1941" and such, it might be
enough of a language extension to eliminate any further need for additional
packages. Hmmmmmmmmm...............

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:3AB2D1EF.B2CA8117@acm.org...
> This proposal limits you to a fixed set of formats. If the format you
> need is not in that set, you are out of luck.
>
> I'm toying with providing image functions for the individual parts of a
> date or time. This would allow the client to combine them in any manner
> desired. I'm currently chewing on what to do with the am/pm part of a
> 12-hour hour. When I come up with something usable I'll post it here for
> comment.
>
> --
> Jeff Carter
> "I waggle my private parts at your aunties."
> Monty Python & the Holy Grail