As everybody said here all the time. Store as YYYY-MM-DD, the international convention used to be easy to handle and sort things, and presents as desired.
How do I convert a sting from ‘01/31/2023’ to a sql date?
Just make sure the web app is sending the date as SQLDate format and the iOS side should be able to parse it with your existing code. Date.FromText can take SQLDate no problem.
There’s gonna be something like
Value=Str(d.Day)+"/"+Str(d.Month)+"/"+Str(d.Year)
Should be like
Value=d.SQLDateDim x As String = “01/31/2023” // origin as mm/dd/yyyy
Dim p() As String = x.Split("/") // split the parts
Dim d As New Date(p(2).CLong, p(0).CLong, p(1).CLong) // creates a new object date from the collected values
MsgBox d.SQLDate // show it
The server now returns 2023-01-31
So lsValidTo now contains the same.
The JSON is {“ValidTo”:“2023-01-31”,“IsValid”:“Yes”}
The exception is the same as it did for Canada, now it shows same exception for US.
I should say, It now works for Canada but not US.
Shows same exception.
But you also need to correct your internal logic. It’s not magic. And you need to ask your clients to update the app for the “current” international valid version.
There is no logic , it just displays the date returned from server.
There’s the “model” and the “View”. The model is how things are stored and handled, the view is how things are displayed and inputted. You must to adjust both. Your model stores and handles dates as yyyy-mm-dd, your view must have some logic to get it and present as desired, dd/mm/yyyy, mm/dd/yyyy, or something else.
If you specify a locale, lsValidto must be formatted to match the locale you specify.
And since Locale.Current is depending on the user’s Region Format, that won’t work for everyone obviously (since you’re always sending the same format from your webserver).
So either return a defined format, and read it in that defined locale (and NOT in the user’s device current locale).
Or if you’re switching to SQLDate(Time): obviously send as SQLDate(Time) and read like this:
[quote]Xojo.Core.Date.FromText:
When no locale is specified, the input text can be in either SQLDate (YYYY-MM-DD) or SQLDateTime (YYYY-MM-DD HH:MM:SS) formats.
Var SQLDate As Text = "2018-06-01"
Var myDate2 As Xojo.Core.Date = Xojo.Core.Date.FromText(SQLDate)[/quote]
That’s what I’m doing
Dim lsValidto As Text = dtStatus.Value("ValidTo")
lblValidTo.Text = "Membership Valid To: " + lsValidto <<<<< This now contains "2023-01-31"
App.gdValidTo = Date.FromText(lsValidto, Locale.Current)Read again, please…
What you’ll need to change is: Locale.Current. That’s just plain wrong for this use-case.
Your right, I removed Locale.Current and it now works. Problems is now I have to push a new version out.
That is such a pain. I was hoping I could fix it on the server.
[quote=477879:@Richard Albrecht]Your right, I removed Locale.Current and it now works. Problems is now I have to push a new version out.
That is such a pain. I was hoping I could fix it on the server.[/quote]
You can “fix” it on your server by changing the IsValidto dates to only return 01 to 12 for month and day. And be the same, so 01/01/xxxx if expires in January, 02/02/xxxx if expires in February and so on.
You will need to give your users some extra days. A date that is 01/31/2023 will need to be changed to 02/02/2023, but also 01/02/2023 should change to 02/02/2023.
App has been submitted for review!
Well, only if… there is a useful language/region in the request headers. Then the server could format it in a “likely-that-localization” way.
But even then: bad idea (to send/interpret “localized” formats).
Yup. That needs an update anyway. Otherwise it will never be correct in every device’s current locale.
In such a situation, I’d use a SQLDate, too. A well defined standard for both server/client.Localization is wrong here.
But I would continue to send the old/wrong “ValidTo”, so that existing/old app versions continue to work as now by reading dtStatus.Value("ValidTo") (at least for some of your users). Have the server send an additional “ValidTo_AsSQLDate”, which the upcoming appversions are interpreting as SQLDate dtStatus.Value("ValidTo_AsSQLDate") (ignoring the old/wrong/localized field).