date time type differences between vfp5 and vfp6
Hamilton Chua
in
VISUAL FOXPRO VER. 5 (Command window)
a={02/02/2000} && when pressing enter key, the date stored to a
b={02/03/2000} && when pressing enter key, the date stored to b
?=a-b && result = -1
while
in
VISUAL FOXPRO VER. 6 (Command window)
a={02/02/2000} && when pressing enter key an error occurs
produces an error
ERROR:
ambiguous date/datetime constant. Use the format:
{^yyy-mm-dd [hh[:mm[:ss]] [alp]]}
Thanks,
Paul Borowicz
VFP 6.0 has been enhanced to provide better support for year 2000
applications. The example you have given--02/03/2000--is ambiguous; does it
mean February 3, 2000 or March 2, 2000. If you don't want this error
message just:
SET STRICTDATE TO 0
HTH,
--Paul
Hamilton Chua <hgcph...@pacific.net.ph> wrote in message
news:88r9lb$1d0$1...@newton.pacific.net.sg...
Craig Berntson
problems. Instead, use:
{^2000-02-03}
--
Craig Berntson
MCP, Microsoft FoxPro MVP
eSolutions Services
Salt Lake City Fox User Group
http://members.home.com/foxpro
Gwilym Morris
Surely this cannot be improved date support, the purpose of the SET DATE
command is to tell foxpro exactly what date format is being used by e.g.
21/02/2000
SET DATE BRITISH
a={21/02/2000}
produces the error message
SET DATE BRITISH
a=ctod('21/02/2000')
works as it should.
The curly brackets, which I seem to remember were introduced to make it
quicker to specify a date, are not checking the SET DATE status, otherwise
fox would know what date was being specified. It is submitted that it can
only be a bug or undesirable program operation - if not why should foxpro
fail on {} when it works with ctod() ?
Why should STRICTDATE (which I agree works and gives a correct answer of
zero on a-b) make an ambiguous date unambiguous. Is it a switch to
completely change the operation of the {} ?
Could any Microsoft people shed light on this ?
Gwilym
-----Original Message-----
From: Paul Borowicz <paul_b...@provide.net>
Newsgroups: microsoft.public.fox.programmer.exchange
Date: 21 February 2000 13:06
Subject: Re: date time type differences between vfp5 and vfp6
>Hi:
>
>VFP 6.0 has been enhanced to provide better support for year 2000
>applications. The example you have given--02/03/2000--is ambiguous; does
it
>mean February 3, 2000 or March 2, 2000. If you don't want this error
>message just:
>
>SET STRICTDATE TO 0
>
>HTH,
>
>--Paul
>
>Hamilton Chua <hgcph...@pacific.net.ph> wrote in message
>news:88r9lb$1d0$1...@newton.pacific.net.sg...
>> does anyone know why
>>
>> in
>> VISUAL FOXPRO VER. 5 (Command window)
>> a={02/02/2000} && when pressing enter key, the date stored to a
>> b={02/03/2000} && when pressing enter key, the date stored to b
>> ?=a-b && result = -1
>>
>> while
>> in
>> VISUAL FOXPRO VER. 6 (Command window)
>> a={02/02/2000} && when pressing enter key an error occurs
>>
>> produces an error
>> ERROR:
>> ambiguous date/datetime constant. Use the format:
>> {^yyy-mm-dd [hh[:mm[:ss]] [alp]]}
>>
>> Thanks,
>>
>>
>
>
Paul Borowicz wrote in message ...
>Hi:
>
>VFP 6.0 has been enhanced to provide better support for year 2000
>applications. The example you have given--02/03/2000--is ambiguous; does
it
>mean February 3, 2000 or March 2, 2000. If you don't want this error
>message just:
>
>SET STRICTDATE TO 0
>
>HTH,
>
>--Paul
>
Anders Altberg
SET DATE BRITISH
a=ctod('21/02/2000')
The improvement is that we can catch and avois date literals or strings that
depend on a particular SET DATE, that's the ambiguity. Another improvement
is the date function DATE(year, month, day), which doesn't accept 2-digit
years. It does go down to the year 100.
-Anders
"Gwilym Morris" <g.mo...@anglia.ac.uk> wrote in message
news:OjPfIeHf$GA....@cppssbbsa02.microsoft.com...
Gene Wirchenko
>I disagree with Paul's recommendation. SET STRICTDATE TO 0 can hide Y2K
>problems. Instead, use:
>
>{^2000-02-03}
Unfortunately, this doesn't work in filter expressions. The
filter expression ends up not having the caret and VFP complains
unless set strictdate to 0.
[snipped previous]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Gwilym Morris
- but where does it leave us when our clients expect to enter dates in
their native format which depends on SET DATE and would object most strongly
if we insisted they enter yyyy-mm-dd into a date field
It seems as if MicroSoft may have solved an existing problem but created a
new one by ignoring SET DATE which is concerned with locale not with year
2000
Anders Altberg wrote in message ...
>Gwilym
> SET DATE BRITISH
> a=ctod('21/02/2000')
>does produce an error if you SET STRICTDATE TO 2.
>The improvement is that we can catch and avois date literals or strings
that
>depend on a particular SET DATE, that's the ambiguity. Another improvement
>is the date function DATE(year, month, day), which doesn't accept 2-digit
>years. It does go down to the year 100.
>-Anders
[previous snipped]
Anders Altberg
-Anders
"Gene Wirchenko" <ge...@shuswap.net> wrote in message
news:38b1f318...@news.shuswap.net...
Anders Altberg
The user will pick dates from a calender or type them in a textbox as per
usual:
FUNCTION Valid
LOCAL lnYear, lnMonth, lnDay
lnYear = YEAR(This.value)
lnMonth = MONTH(This.Value)
lnDay= DAY(this.Value)
REQUERY('theview')
the view'd defined with:
CREATE VIEW theview AS ;K
SELECT * FROM Table WHERE date = DATE(?lnYear,?lnMonth,?lnDay)
or for a query
SELECT ... WHERE date => DATE(lnYear,lnMonth,lnDay) INTO CURSOR Q
If the user is typing in dates you can force four-digit entry and check
This.Text in the Valid to see if there are four digits in the year part. You
can also check that in KeyPress.
-Anders
"Gwilym Morris" <g.mo...@anglia.ac.uk> wrote in message
news:OrsQpMUf$GA.306@cppssbbsa04...
David Frankenbach
One other significant problem solved by VFP6 and the the new strict date
deals with the compilation of {} constants being affected by the SET DATE in
effect at compile time, which might be different that the runtime SET DATE
which means the constants can be out of synch.
Compile this code with
SET STRICTDATE 0
SET DATE AMERICAN
function SetDateTest( pdTest )
a = {2/21/2000}
return ( pdTest < a )
run it from the command window to test it.
? SetDateTest( {2/22/2000} )
? SetDateTest( {2/21/2000} )
? SetDateTest( {2/20/2000} )
Then SET DATE BRITISH and rerun the same tests and it will fail.
because 22,21,20 are not valid months. Now go edit the code by putting just
a space in it and run again. Now it will always return .f. because the
2/21/2000 date compiled as { / / } because it's invalid under the changed
SET DATE that was in effect at compile time.
These kinds of problems are near impossible to find during development. If
you are doing multinational development use strictdate 2 and change all of
your date constants and you will not have these kinds of problems.
--
df - (Microsoft FoxPro MVP)
http://www.geocities.com/ResearchTriangle/9834/
"Gwilym Morris" <g.mo...@anglia.ac.uk> wrote in message
news:OjPfIeHf$GA....@cppssbbsa02.microsoft.com...
> Paul and Everyone,
>
> Surely this cannot be improved date support, the purpose of the SET DATE
> command is to tell foxpro exactly what date format is being used by e.g.
> 21/02/2000
>
> SET DATE BRITISH
> a={21/02/2000}
>
> produces the error message
>
> SET DATE BRITISH
> a=ctod('21/02/2000')
>