Wirt Atmar <[log in to unmask]> writes:
 
>But there is a second productivity attribute, too, and that is processing
>time. Let us presume that requirement is to find all of the invoices for May,
>regardless of the year, and the date is numerically encoded as a Julian date,
>offset from some arbitrary date, as it is MANMAN, then the query must be
>formulated something like this (using a generic query syntax):
>
>     find when substring(ascii(date(jd(DATE-DATAITEM,offset)))) = 05
>
 
One of the delights of checking this newsgroup is the opportunity to be
called a technophiliac and to realixe that I'm not (at least by that def-
inition) a sexual pervert nor liable to bleed to death if I cut myself on
the sharp wit of Wirt Atmar!
 
However - give his trenchant repsonse to my response to (...) why do we limnit
ourselves to
substring(ascii(date(jd etc
when what we really want to say is
subdate ("May" ,DateField, some other arcane syntax details )
and let the parser figure it out given the internal structure of the
data field as known from the respository?
 
This would, I believem be analagous to my other rfavorite dinosaur language
COBOL, where MOVE ing data betwee numeric fields relies on the compiler being
smart enough to know just how it has previously defined numeric fields.
 
All I have to do is to say:
 
Field ExpirationDate:Date(DayOfYear;7);
 
and ALL of the date related extract features would be available, just as if
I had saif
Field PaymentDate:Date(YYYYMMDD);
 
In other words internal representations should not affect parsing for
extract purposes. What counts is the logical definition of the data.
 
<Step down from the soapbox - Tony!>