ParseDate conversion trouble

Hello Everyone,

Just tried to use ParseDate from the Xojo ParseDate website and I can’t seem to get this simple example to work on Windows 8.1 or OS X for a web application. Here is my example program and the code below it:

ParseDate.xojo_binary_project

[code] Dim theDate as New Date
Dim converted as Boolean

// Attempt to convert the string “12/31/2013” to a date. If
// the conversion succeeds, theDate variable contains the converted date.
converted = ParseDate(“12/31/2013”, theDate)
If converted then
MsgBox("Converted to: " + theDate.AbbreviatedDate)
Else
MsgBox(“Could not convert the string to a date.”)
End If

'See http://documentation.xojo.com/index.php/ParseDate[/code]

When I run this I always get the message “Could not convert the string to a date”. What am I missing to make this example work?

Thanks for your help.

Works fine for me running your exact code.
Mac OS 10.10
Xojo 2014r2.1

Oops, just noticed your statement you are running a web app. Not sure what needs to happen, but I believe this only works on desktop. Have to do something else for web.

Its all good. I am also running on Mac OS X 10.10 and Windows 8.1 on Xojo 2014 r2.1 and both don’t seem to work for the Web App.

Thanks for giving it a go :slight_smile:

Someone will come along this evening and show you what you need to do for the web app. I’ve just not delved into web apps.

[quote=140876:@Eugene Dakin]Its all good. I am also running on Mac OS X 10.10 and Windows 8.1 on Xojo 2014 r2.1 and both don’t seem to work for the Web App.

Thanks for giving it a go :)[/quote]

Confirmed under Windows 10. Definitely a problem, cannot convert to a date.

Workaround : use split to get each term, and a constructor for the date object.

Thanks for your help Michel,

I’ll submit a feedback report.

Feedback created:

<https://xojo.com/issue/36396>

Thanks for reviewing code and making Xojo better!

Thanks for the tip about the Split method Michel,

Here is workaround code:

[code] Dim theDate as New Date
Dim SD as String

// Attempt to convert the string “12/31/2013” to a date.
SD = “12/31/2013”
'MsgBox theDate.AbbreviatedDate
Dim DateArray(-1) as String
DateArray = Split(SD, “/”)

theDate.Month = Val(DateArray(0))
theDate.Day = Val(DateArray(1))
theDate.Year = Val(DateArray(2))

MsgBox theDate.ShortDate
'See http://documentation.xojo.com/index.php/ParseDate[/code]

Another work around would be to create an in memory db and use sql date functions to parse date

I’m betting it has to do with the locale in a console app (which is basically what web apps are) is different than a GUI app

Im just diving off to eat dinner but give it a try in a simple console app & see if you get the same results

[quote=140899:@Norman Palardy]I’m betting it has to do with the locale in a console app (which is basically what web apps are) is different than a GUI app

Im just diving off to eat dinner but give it a try in a simple console app & see if you get the same results[/quote]

Hi Norm,

Yes your right, the same problem happens with the original code in a Desktop and Console app on Windows 8.1 (Haven’t tried OS X 10.10).

Works fine here on Windows 8.1 with Xojo 2013r2 and Xojo 2014r2.1, i just had to adjust the datestring to “31-12-2013” as here we start with the day, then the month and then the year and the seperator is a dash. All as specified in the regional settings as Norman mentioned.

Norman, your right

Changing Windows 8.1 Language from English (Canada) to English (United States) makes ParseDate work. To change the language on Windows 8.1 open control panels → Clock Language and Region → Language and then add English (United States) and Move Up the language to the top to give it priority.

To Change the language on OS X 10.10 to make ParseDate work go to System Preferences → Language and Region → Region (Change from Canada to United States) and it works.

Changing from United States to Canada causes ParseDate to stop working. This information was updated in Feedback 36396.

Right
Parse date is 100% dependent on the current settings
Thats not new
http://documentation.xojo.com/index.php/ParseDate
The Text parameter must be a valid string representation of a date. ParseDate uses the current date formats that are specified in the regional/international system settings on the user’s computer. It recognizes those formats. For that reason, the specific formats that ParseDate will support on a particular computer cannot be specified. If you are having problems with a date format, check the International formats (OS X), Regional Settings (Windows), or equivalent feature on Linux to be sure that the format you are using is specified.

Thanks Norman. It looks like the format for a date in Canada on computers is YYYY/MM/DD I found out according to ISO 8601, which is [YYYY]-[MM]-[DD]T[hh]:[mm]:[ss] - It looks like this reduces the amount of code needed to resolve and compute dates.

I did a quick check on Wikipedia (Yes, it may not be accurate) and here is a statement on time formats in Canada (wow, confusing!)

[quote]All 3 main types are used in Canada – in French and in English.[29][30]
Social Insurance applications for Canada use DMY format.[31]

Passport applications[32] and tax returns[33] use YYYY MM DD.

Immigration Canada Stamps use DD/MM/YYYY and Canada Customs Stamps use MM/DD/YYYY.

Nearly all English newspapers use MDY (MMM[M] D, YYYY).[34]

The default date format used by Microsoft Windows for English Canada for all-numeric dates (short-dates) is DD/MM/YYYY, and for long dates is MMMM D, YYYY in Windows XP and MMMM-DD-YY in later versions; for French Canada it is YYYY-MM-DD for short-dates and D MMMM YYYY for long-dates.[/quote] Canada Time Zones

Because all three types are used in Canada, then it may be in my best interest to internally use my own ‘standard’ type and convert it manually for the particular end-user.

Input as free form text is problematic since what date is 1/11/10 ? (that was fun right around Y2k)
With long term gas supply contracts who knows
Jan 11, 2010 ?
Nov 1, 2010 ?
Nov 10, 2001 ?
Oct 11, 2001 ?

So none of our inputs EVER had date as a single field they were always split apart to reduce ambiguity (and they were all numeric so folks who had to input data rapidly could do it with one hand on the numeric keypad)

Internally we used a format that was also unambiguous YYYYMMDD so it just naturally sorted nicely too
Jan 1, 2010 was 20100101

Internally I’d use sql date since its VERY predictable

That’s a great idea Norman! Thank you.