This is the used code. I always get Test failed.
Current Xojo, current Sequoia, MacBook Pro m1
Var New_Date As New Date(2024,10,2)
Parsed = ParseDate("2025-02-20", New_Date)
If Parsed Then
System.DebugLog "Date Parsed !"
Else
System.DebugLog "Test failed: " + New_Date.SQLDate
Return
End If
I strongly advise you to upgrade your system to use DateTime instead of Date. That said, you are trying to convert a SQL like date and parsedate() is trying to use your local format.
Hi Rick,
You are 100% correct.
Once I read your anser, I was asking myself “What is my local format ?”
During some seconds, I wanted to as Xojo to report a date, but I was stopped because I do not know how to do that (at first).
In the end, I used DD-MM-YYYY and run: it worked !
PS: I have bad memory, ut I do not recall when I wrote a date in this format while programming.
To use DateTime, that defaults the parsing as “yyyy-mm-dd [hh:mm:ss]”, you could do like this:
Var strDate As String = "2025-02-20" // try something wrong as 2025-02-33
Var new_date As DateTime
Try
new_date = DateTime.FromString(strDate)
Catch
new_date = Nil
End
If new_date = Nil Then
System.DebugLog "Invalid Date!"
Else
System.DebugLog "Date Parsed: " + new_date.ToString
End
break
Thank you, I will do that.
My code was an example because the real code parse a DateTime variable and - I was writing wrong code - I finally replace Value.SQLDate with a date value, today, so I am sure of the result (2024 vs 2025).
The error was elsewhere.
ParseDate is a bit more robust with the things you can throw at it. From what reason does this advice stem? What advantage does the less-flexible function have?
Both Date and ParseDate are deprecated since 2019, and will be removed at some time. Moving towards DateTime is a must.
I’ll let you know when I start holding my breath for the API 1.0 removal 
Edit: To be clear, I do agree that DateTime is a more modern class in terms of handling edge cases with dates and times - but it is also more difficult to use. For Emile, the flexibility of Date is going to be far easier. I just don’t think “omg it’s deprecated” in a framework that’s full of technical debt is a base for advice.
Ok. You know I’m ok with personal choices and personal risks.
But, just out of curiosity, why you think that ParseDate is more flexible?
I have no problems on not knowing things and learning, but I’m not aware about advantages, I see the other way around, at least theoretically.
Edit: I see your edit. I’m ok, no need of further explanations.
DateTime.FromString requires that you know the Locale to get anything out of it at all.
ParseDate was built to give you its best guess and it would try many different approaches before returning false. You are certainly prone to get a bad result from that, but for someone like Emile just looking for easy, it’s a much more friendly function.
Edit: Well crap. Here I was thinking ParseDate could handle the HTTP date format and it does not. I guess forget every opinion I’ve had on ParseDate 
You know, for the design of things perspective, guessing formats is considered a not great choice. I think Xojo is just following more and more rigid choices about less hidden side effects (caused by too flexible models silently failing), mutability, etc. Yes, it has a cost on people that like things more like a very flexible script language. We see some new users, sometimes, trying things we saw in the CLIPPER/FOX old times. 
Keep in mind that the entire Xojo IDE before 2019 was written in API 1. It’s okay to say that it’s deprecated, but you should amend the statement “and will be removed at some time” with “in the far off distant future”.
We, including you, don’t know what parts they already upgraded since you left, and some parts will be left in the framework but not being used in the IDE anymore (like, maybe, Date / ParseDate instead of DateTime). That legacy will be there rotting hidden until someone says “hey, there’s a thing here malfunctioning” in the legacy code. I can’t say how far something like that will be.
Date field delimiter: I see, used in URLs, both of them (- and /). And, a simple ReplaceAll is easy (I have one in the Event I was working when I used ParseDate.
I must say, I also used it because my previous attemps were failing and I wantd to know why. Now I know.
I have to change my way of coding and stop doing it in two times: a fas one to know if the design I have in mind works and a better coding in a seco error checkings, etc.
As Tim wrote, “I choosed the fast way” and it became a long way to make it work.
Think:
myDate.Day = myDate.Day + 1 is faster than using a DateTime and a DateInterval… and here I went ! 
It seems to me that is OK if you are writing a tiny example to test something. Then you can also look at it and decide that error checking is needed here and here, logging is needed there and there (or whatever else you need to integrate it into your app). Usually I need to copy over a number of methods from the app, too, into the test. That also means that this test can be incorporated into the Unit Test suite in the app if I think it’s worth it.
In both cases I have to verify the syntax in the documentation when writing, so…