On 4-May-07, at 9:02 AM, Steve Garman wrote:
>> I think a possible approach would be to change the given
>> datestring into
>> something that we know RB's parse date can digest, and then just
>> hand the
>> modified parameter over to RB's parse date and return its result.
>
> As I'm not confident I understand parseDate's behaviour under all
> circumstances on all locales and platforms, I've decided against
> risking
> that.
>
> I've posted corrected (I hope) code at
> <http://rb.sgarman.net/validDate.php>
I'm not 100% sure of what parsedate does or uses either in all all cases
So I put together a test in 5.5.5
dim month as integer
dim day as integer
for month = 0 to 13
for day = 0 to 32
checkDate(format(day,"0") + "/" + format(month,"0") +"/2007" )
next // day
next // month
Sub Checkdate(s as string)
dim d as date
dim validStr as string
listBox1.addRow s
if parseDate(s,d) then
validStr = "valid"
else
validStr = "not valid"
end if
listbox1.cell(listBox1.lastIndex,1) = validStr
Imagine my surprise when parsedate told me that 13/1/2007 is NOT valid
Especially since my date format settings ARE set to dd/mm/yyyy
So I switched to US (mm/dd/yyyy) and got the same results
I tried other national format settings and got the same results
So under 5.5.5 regardless of what date format I set parsedate gives
me the same result all the time
2005r4 and 2006r4 do the same
None of these versions seems to use anything other than mm/dd/yyyy as
the expected format in any tests I have done.
At least it ignore the setting of the International Preference pane.
It may behave differently under different localized installs of OS X
but I don't have those to try this with
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
