Can we rely on CTOD()'s empty date feature?

It is handy to use CTOD() on a text date entry to see if the
entered date is valid or not. CTOD() returns an empty date
if an invalid date is passed:

? CTOD("23/67/823928")

But I noticed that this behavior is not documented in the
help file in VFP6, VFP8, VFP9. I tend to be leary of relying
on bahavior that is not documented.

-- TRW
_______________________________________
t r w 7
at
i x dot n e t c o m dot c o m
_______________________________________

Dan
Wed Mar 23 12:29:37 CST 2005

It's been that way since dBase II on CP/M so I wouldn't look for it to
change, but you're right it should be doc'd.

There's a feedback link at the bottom of every help topic. Clicking that
will send email (with links to the topic in question) directly to the help
authors. (And they really do read them! <g>)

Dan

Tim Witort wrote:
> It is handy to use CTOD() on a text date entry to see if the
> entered date is valid or not. CTOD() returns an empty date
> if an invalid date is passed:
>
> ? CTOD("23/67/823928")
>
> But I noticed that this behavior is not documented in the
> help file in VFP6, VFP8, VFP9. I tend to be leary of relying
> on bahavior that is not documented.
>
> -- TRW
> _______________________________________
> t r w 7
> at
> i x dot n e t c o m dot c o m
> _______________________________________

trw7at
Wed Mar 23 13:16:57 CST 2005

Dan Freeman seemed to utter in
news:#m9oGZ9LFHA.3512@TK2MSFTNGP15.phx.gbl:

> It's been that way since dBase II on CP/M so I wouldn't look for it to
> change, but you're right it should be doc'd.
>
> There's a feedback link at the bottom of every help topic. Clicking
> that will send email (with links to the topic in question) directly to
> the help authors. (And they really do read them! <g>)
>
> Dan

I'll send a suggestion that this behavior be documented.
Thanks, Dan.

-- TRW
_______________________________________
t r w 7
at
i x dot n e t c o m dot c o m
_______________________________________

Gene
Wed Mar 23 15:21:23 CST 2005

On Wed, 23 Mar 2005 19:16:57 GMT, trw7at@ixdot.netcomdotcom (Tim
Witort) wrote:

>Dan Freeman seemed to utter in
>news:#m9oGZ9LFHA.3512@TK2MSFTNGP15.phx.gbl:
>
>> It's been that way since dBase II on CP/M so I wouldn't look for it to
>> change, but you're right it should be doc'd.
>>
>> There's a feedback link at the bottom of every help topic. Clicking
>> that will send email (with links to the topic in question) directly to
>> the help authors. (And they really do read them! <g>)
>>
>> Dan
>
>I'll send a suggestion that this behavior be documented.
>Thanks, Dan.

I was going to suggest using date() but
? date(2005,13,1) && error
? date(2005,11,31) && NO error: prints empty date
? date(10000,11,31) && error

Sincerely,

Gene Wirchenko

trw7at
Thu Mar 24 11:24:31 CST 2005

Gene Wirchenko seemed to utter in news:fan341lqqogjg8dsll2e6pn44539mqa33k@
4ax.com:

> On Wed, 23 Mar 2005 19:16:57 GMT, trw7at@ixdot.netcomdotcom (Tim
> Witort) wrote:
>
>>Dan Freeman seemed to utter in
>>news:#m9oGZ9LFHA.3512@TK2MSFTNGP15.phx.gbl:
>>
>>> It's been that way since dBase II on CP/M so I wouldn't look for it to
>>> change, but you're right it should be doc'd.
>>>
>>> There's a feedback link at the bottom of every help topic. Clicking
>>> that will send email (with links to the topic in question) directly to
>>> the help authors. (And they really do read them! <g>)
>>>
>>> Dan
>>
>>I'll send a suggestion that this behavior be documented.
>>Thanks, Dan.
>
> I was going to suggest using date() but
> ? date(2005,13,1) && error
> ? date(2005,11,31) && NO error: prints empty date
> ? date(10000,11,31) && error

Yeah, DATE() is much more strict than CTOD(). Plus, I am
starting with a character date. It's much more convenient
to feed that to CTOD() than to parse out the year, month,
and day as numeric values. CTOD()'s returning an empty
date on a bogus date is almost more useful than it's
intended function! It's like having an ISDATE() function
for strings. You just need to fiddle with the STRICTDATE
setting whenever you use it to avoid the warnings.

-- TRW
_______________________________________
t r w 7
at
i x dot n e t c o m dot c o m
_______________________________________

Gene
Thu Mar 24 14:30:37 CST 2005

On Thu, 24 Mar 2005 17:24:31 GMT, trw7at@ixdot.netcomdotcom (Tim
Witort) wrote:

>Gene Wirchenko seemed to utter in news:fan341lqqogjg8dsll2e6pn44539mqa33k@
>4ax.com:

[snip]

>> I was going to suggest using date() but
>> ? date(2005,13,1) && error
>> ? date(2005,11,31) && NO error: prints empty date
>> ? date(10000,11,31) && error
>
>Yeah, DATE() is much more strict than CTOD(). Plus, I am

But not strict enough.

At least, it is not that stupidity in JavaScript where
.getMonth() returns one less than the month number. Off-by-one error,
anyone?

>starting with a character date. It's much more convenient
>to feed that to CTOD() than to parse out the year, month,
>and day as numeric values. CTOD()'s returning an empty
>date on a bogus date is almost more useful than it's
>intended function! It's like having an ISDATE() function
>for strings. You just need to fiddle with the STRICTDATE
>setting whenever you use it to avoid the warnings.

Put a wrapper around it?

Sincerely,

Gene Wirchenko

Dan
Thu Mar 24 15:59:06 CST 2005

Gene Wirchenko wrote:
> At least, it is not that stupidity in JavaScript where
> .getMonth() returns one less than the month number. Off-by-one error,
> anyone?

Everything (EVERYTHING) in Java/javascript is zero-based, so at least it's
by design.

You want stupidity? In "real" Java, the Date.GetYear() method returns
something other than 4 digits. For the longest time, people assumed it was
the last two digits of the year. Then came Y2K and it started returning 100.

It's actually the number of years elapsed since 1900. By design.

STUPID feature for a relatively new language!

Dan

Mike
Fri Mar 25 01:39:57 CST 2005

On Thu, 24 Mar 2005 17:24:31 GMT, trw7at@ixdot.netcomdotcom (Tim
Witort) wrote:

>Gene Wirchenko seemed to utter in news:fan341lqqogjg8dsll2e6pn44539mqa33k@
>4ax.com:
>
>> I was going to suggest using date() but
>> ? date(2005,13,1) && error
>> ? date(2005,11,31) && NO error: prints empty date
>> ? date(10000,11,31) && error
>
>Yeah, DATE() is much more strict than CTOD().
You call that _more_ strict ? When it is totally inconsistent ?

> Plus, I am
>starting with a character date. It's much more convenient
>to feed that to CTOD() than to parse out the year, month,
>and day as numeric values. CTOD()'s returning an empty
>date on a bogus date is almost more useful than it's
>intended function! It's like having an ISDATE() function
>for strings. You just need to fiddle with the STRICTDATE
>setting whenever you use it to avoid the warnings.
I use CTOD() in precisely this fashion, VFP5 and 8, no problem.

Mike.

Stefan
Fri Mar 25 04:29:07 CST 2005


"Mike McDowall" <m.a.mcdowall@ed.com> schrieb im Newsbeitrag
news:2tf741pj33qhegs4lh460k6g8kg2gavfaa@4ax.com...
> On Thu, 24 Mar 2005 17:24:31 GMT, trw7at@ixdot.netcomdotcom (Tim
> Witort) wrote:
>
>>Gene Wirchenko seemed to utter in news:fan341lqqogjg8dsll2e6pn44539mqa33k@
>>4ax.com:
>>
>>> I was going to suggest using date() but
>>> ? date(2005,13,1) && error
>>> ? date(2005,11,31) && NO error: prints empty date
>>> ? date(10000,11,31) && error
>>
>>Yeah, DATE() is much more strict than CTOD().
> You call that _more_ strict ? When it is totally inconsistent ?

CTOD() may fail unexpectedly while dealing with different (international)
Set Date settings.
That may sound not related when your app runs in your area only, but
the code will actually be affected when for example your customer is a
French restaurant and you have Set Sysformats On, so that VFP uses
the current user's Windows settings:
? CMONTH( CTOD("05/01/03") )
&&SET SYSFORMATS ON
Set Date To British
? CMONTH( CTOD("05/01/03") )

I believe a good rule-of-thumb is to avoid any conversion of Date
types to Character and back, except for displaying things in captions and
MessageBoxes etc..


hth
-Stefan


--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------

Mike
Fri Mar 25 08:33:52 CST 2005

On Fri, 25 Mar 2005 11:29:07 +0100, "Stefan Wuebbe"
<stefan.wuebbe@gmx.de> wrote:

>CTOD() may fail unexpectedly while dealing with different (international)
>Set Date settings.
>That may sound not related when your app runs in your area only, but
>the code will actually be affected when for example your customer is a
>French restaurant and you have Set Sysformats On, so that VFP uses
>the current user's Windows settings:
> ? CMONTH( CTOD("05/01/03") )
> &&SET SYSFORMATS ON
> Set Date To British
> ? CMONTH( CTOD("05/01/03") )
Thanks for the warning Stefan.

>I believe a good rule-of-thumb is to avoid any conversion of Date
>types to Character and back, except for displaying things in captions and
>MessageBoxes etc..
Ah, and I believe a good rule of thumb is never to allow users to edit
anything other than character data <g>

Actually, dates are not so bad - but we need to be able to store
partial dates and special codes, and the best way we have found is to
use character data.

Numeric fields are a different matter :-( I never let users edit
numeric data.

Mike.

Gene
Fri Mar 25 13:49:12 CST 2005

On Thu, 24 Mar 2005 13:59:06 -0800, "Dan Freeman" <spam@microsoft.com>
wrote:

>Gene Wirchenko wrote:
>> At least, it is not that stupidity in JavaScript where
>> .getMonth() returns one less than the month number. Off-by-one error,
>> anyone?
>
>Everything (EVERYTHING) in Java/javascript is zero-based, so at least it's
>by design.
>
>You want stupidity? In "real" Java, the Date.GetYear() method returns

No, but I frequently do not have the choice.

>something other than 4 digits. For the longest time, people assumed it was
>the last two digits of the year. Then came Y2K and it started returning 100.
>
>It's actually the number of years elapsed since 1900. By design.
>
>STUPID feature for a relatively new language!

I was thinking of that one, too. When I looked up the function
just to be sure that I had the capitalisation right, I happened on a
Web page giving an example of a dynamic page with the date. That was
on March 23, 105 according to the Web page. My, just 26 years after
the Pompei eruption!

Sincerely,

Gene Wirchenko

Gene
Fri Mar 25 13:49:13 CST 2005

On Fri, 25 Mar 2005 07:39:57 +0000, Mike McDowall
<m.a.mcdowall@ed.com> wrote:

>On Thu, 24 Mar 2005 17:24:31 GMT, trw7at@ixdot.netcomdotcom (Tim
>Witort) wrote:
>
>>Gene Wirchenko seemed to utter in news:fan341lqqogjg8dsll2e6pn44539mqa33k@
>>4ax.com:
>>
>>> I was going to suggest using date() but
>>> ? date(2005,13,1) && error
>>> ? date(2005,11,31) && NO error: prints empty date
>>> ? date(10000,11,31) && error
>>
>>Yeah, DATE() is much more strict than CTOD().
>You call that _more_ strict ? When it is totally inconsistent ?

What "totally inconsistent"? It failed to throw an error in one
case.

[snip]

Sincerely,

Gene Wirchenko

Stefan
Tue Mar 29 02:19:43 CST 2005


>>I believe a good rule-of-thumb is to avoid any conversion of Date
>>types to Character and back, except for displaying things in captions and
>>MessageBoxes etc..
> Ah, and I believe a good rule of thumb is never to allow users to edit
> anything other than character data <g>

Oh, then our rules-of-thumb don't play well together <s>

> Actually, dates are not so bad - but we need to be able to store
> partial dates and special codes, and the best way we have found is to
> use character data.
>
> Numeric fields are a different matter :-( I never let users edit
> numeric data.

Interesting, why not?


-Stefan


--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------

Mike
Tue Mar 29 06:03:26 CST 2005

On Tue, 29 Mar 2005 10:19:43 +0200, "Stefan Wuebbe"
<stefan.wuebbe@gmx.de> wrote:

>
>>>I believe a good rule-of-thumb is to avoid any conversion of Date
>>>types to Character and back, except for displaying things in captions and
>>>MessageBoxes etc..
>> Ah, and I believe a good rule of thumb is never to allow users to edit
>> anything other than character data <g>
>
>Oh, then our rules-of-thumb don't play well together <s>
>
>> Actually, dates are not so bad - but we need to be able to store
>> partial dates and special codes, and the best way we have found is to
>> use character data.
>>
>> Numeric fields are a different matter :-( I never let users edit
>> numeric data.
>
>Interesting, why not?
Suppose 0 is a valid value. If a user deletes an entry with the
intention of leaving it blank to return later and enter data, the
value contained in the field is actually 0. Nasty key traps required :
yuk !

Mike.