> Date: Sat, 28 Jan 1995 22:11:36 GMT
 >

 > : I wrote a program a few months ago to pull out certain info
 > : based upon a date comparison
 > : ( IF m_DATE.WORKED => ICONV(07.01.94,'D') THEN )
 > : and it (seemed to) worked fine _until_ the change of the calendar
 > : year...  Then it simply stopped working!  I've changed the line
 > : to directly check for the internal date
 > : ( IF m_DATE.WORKED => 9769 THEN )
 > : and it's working again!
 > :
 > : I guess my question is WHY this happened?  I know, big question...
 > : But is there anything noticeable??  I'm stumped on this one.  Maybe
 > : something with the ICONV function that I'm doing incorrectly?
 >
 > I suspect, with no actual knowledge, that this is one of the
 > loveable side-effects of programming with typeless data.  In order
 > to untangle such conundra, think about it from the computer's point
 > of view:
 >
 > Consider the string 07.01.94.  This is a decimal number, not a string.
 > I know that, because strings are coded "07.01.94".  So the compiler,
 > probably, makes the string into a number;  then the runtime turns the
 > number into a string...  The number is going to be 0701.  :-)  The
 > compiler should have trapped on the statement;  but maybe it decided
 > that the '.94' was a mask, and the mask processor may decide that pure
 > numerick masks are a mask right numeric mask...  Which may decide, on
 > non-numeric data to nop....

Every language has certain features which are truly inspired, and
certain other features which truly inspire frustration and {*filter*}.
I've been fooling around with various dialects of Basic since 1970,
and it's been a while, but if my memory serves, among the syntax trans-
formations which happened somewhere between MAI Basic/4 Business Basic
and Microdata Data/Basic was the redefinition of the ":" (colon) symbol
to indicate catenation instead of string formatting, and the definition
of "" (zilch) to indicate formatting.  How could Data/Basic, which so
sensibly disallowed fortran-style ambiguities in THEN/ELSE nesting, have
such a thing?  Well, as I said, every language has such things.  In
hindsight, it's obvious that "," (comma) for tabbing has never been used
much, and using "," for catenation, and staying with ":" for formatting
would have ensured that many source programs which lacked an operator,
or, in this ICONV case, lacked a pair of quotes, would have been caught
by the compiler.  Info/Basic re-allowed ambiguous THEN/ELSE nesting (just
cause it's prettier, I guess), and sensibly introduced the FMT() syntax
to disallow the old (zilch), convenient, bug-generating syntax, but it
was too late to squelch zilch.

If you followed all that, you will understand how it came about that
Unidata's legacy-compatible UniBasic compiler treats the following lines
of source code more or less equivalently.

X = 07.01.94
X = ("07.01") (".94")
X = FMT( "07.01" , ".94" )

So, then what?  Well, ".94" is an illegal format spec, as can be seen
by checking STATUS() right after any one of the three equivalent lines
shown above.  If you do check STATUS(), you'll see that it = 2, which
means, right after an FMT function, that the format spec was illegal.
And now what does the format function do when the format spec is illegal?
Nothing.  So, you end up with "07.01" ... which, as an American-style
date, means July 1 of the current year in your current time zone.

 > So, leaving many 'implementation opportunities' dangling,
 > the answer is "Code the date as a string, within '"'s."

Yes, or, rather than hard-coding the starting date,
keep it in a control file, or pass it as a parameter from a paragraph.

 > : I'm fairly new to UniBasic programming (no kidding ;) )
 > : and I would greatly appreciate any feedback.
 >
 > You don't need to be new for this one.  :-)  This comment barely skims
 > the surface of the lovable ambiguities herein available.
 >
 > Regards, hve.

regards, bcr.
(speaking for myself, not for Unidata, Inc.)
(affiliation shown for identification purposes, only)
$INCLUDE STANDARD DISCLAIMERS
***
* UniBasic is a registered trademark of Unidata, Inc.
* Other trademarks and registered trademarks are
* the property of their respective owners.