Workaround for WebDatePicker format issue?


With the WebDatePicker, all is fine when the user manually chooses a date. However, when set by code, the format is always “MM/DD/YYY” (see feedback case: <>).
In this feedback report, there’s no workaround, and no discussion either (merely an acknowledgement of reproductivity, but it’s not that helpful as of now…).

I must show, in a WebDatePicker, the date the user has chosen from an object, and, obviously, the wrong format is confusing for most users.
Any known workaround exists?

What version of Xojo are you using?

What value does Session.LanguageCode have for those users?

I just tested this with Xojo 2021r1.1 and FireFox (I use FireFox to test for Spanish and use Chrome for English) and I can’t reproduce this.

This is what I get when I select a date (correct):

when I press the button to change, by code, to today’s date, I get this (also correct):

One I can’t discuss out of the testers channel…
I guessed this issue was also present in earlier versions, but I started this project recently and added the WebDatePicker using the current tested build, so I couldn’t notice it earlier.
Perhaps a good idea to move this question to the testers channel?

Because of another bug, present since several releases (the popup of the date picker not showing with non-us values), I set this in the Opening event of the session:

But I get the same issue without.
(for now, the “users” are just me; it’s being debugged. So it’s french-swiss).

I’ve currently tested with Safari. Any way to use temporarily Firefox with debugging from the IDE without permanently changing it to default so I can try there?
And I tested using a more recent version of Xojo…

Thanks for your inputs.

When your app is running in Safari in debug mode, just fire up firefox and use the same url, likely: and it will open a new (parallel) session in FF which is debuggable too. I added my “debugging” URL as a bookmark in all my browsers.

Update and on a side note: this is quite helpful too, to “simulate” multi user access …

1 Like

Oh, yes, multi-sessions. Funny enough, I’ll have to debug it using several sessions later, but I’ve had not yet thought about how to do that. The answer came before the question :slightly_smiling_face:

Thank you; I confirm it works (multi-sessions using Firefox).
But Firefox too shows the wrong format.

Which is at least a good thing in general. I find those issues the most annoying, where you got things working in browser A and then you look at bowser B and you are close to suicide :-). In all fairness, this is not a Xojo issue only. For my customers I am defining with them their “leading” browser. Obviously this won’t work for apps available publicly in the wild west of the internet. Browser rendering approved a lot, but there are still significant differences here and there, especially with Safari.

And in your sentence (pun intended :grin:), there are just 2 browsers. When considering even just the most used ones, things can be a nightmare (like keypress handling, at least 10 years ago).

My actual issue with date picker’s formatting is :wink:


(less granted) Perhaps a matter of experiences? I’ve had more issues with Edge, IE and Chrome when I used to make (granted, small) websites using php. That was 10 to 5 years ago, though.

Nope, I’m privately using Safari only, unless webpages are not working (some banks are similar big “brands” are still sometimes not working properly), plus there are changes in CSS you can easily do with Chrome, Firefox and even Opera, but ignored by Apple if done during DOM manipulation.

My bad… I should have been sleeping rather than disturbing you all with my persistent lack of correct testing skills…
Actually, the format is more correct than I thought. It’s the provided date which was misleading (it happens that it was the 6th of April 2021). It’s shown like that in the picker: 06/04/2021. Because (1) the separators are wrong (it should read “06.04.2021” here) and (2) I expected a date of June (bug in my code), I saw 06 as being first and all that led me to a wrong conclusion.
My apologises for the wrong question.

My next question is, then: are the wrong separators a Xojo bug that should be addressed, or it’s some sort of “Internet conventions” which one must live with?

Like anyone, they still have to learn :wink:

Ah, OK. Definitively not the same areas than my experiences. I’ll even have to search what DOM stands for :grin:

Edit: done. I’ve used my own path of learning and didn’t bothered in memorising DOM and other abbreviations’ meaning…

We are a de-railing a bit, but as you are the original poster, I guess it is Ok. Yes, we all have to learn, and these days even faster than ever. That’s ONE thing I like about Xojo: it is still doable for one person, often not so much for other tools. But there are limitations too. Take this article for instance: Introduction to cross browser testing - Learn web development | MDN. Very good content, but if you want to follow all recommendations: hire 20 employees :wink: .

Good news for us ist that the out-of-the-box stuff from Xojo Web 2 works (or doesn’t work) the same way on all browsers, with very few minimal glitches. But it is another piece of additional work they have to consider, when adding new functionality It is not enough for them to test them only in one browser.


Well, it turns out I was not so wrong. The first time I set a date in the picker (from code), it’s indeed reversed (month, day, year). Only after setting another date is it shown in the correct order.
So, back to square one. The bug exists.
The good news is I now have a workaround: set a dummy date first and then it should work.

I can replicate this with Xojo 2021r1.1 and FireFox. As you said, only the first time. So if I press the Button before selecting a date with the picker I get this:
instead of 13/06/2021

You may want to add this information to the Feedback Case.

Pressing “Set date” a second time I get 13/06/2021

Edit: I added information to the case with a Workaround that is not perfect, this is it
In the Opening event for the datepicker set a date.
In the Shown event set the date to Nil
You will see the date being cleared after a moment

1 Like

Thank you for adding this to the case. I’ve also added the fact that the separator keeps being wrong (for countries where it shouldn’t be a slash), even after the order comes right.

Your workaround is 100% acceptable for me, as the picker starts in an invisible state.

1 Like

WebDatePicker is based on bootstrap datepicker, I hope in the future we can define our own format and other things. Don’t know how hard that will be to implement. Those with GraffitiSuite can use that DatePicker.


Would be nice (and, in the user’s point of view, probably mandatory).

1 Like

Best example is the “Clipboard”. There is a new async API that works easily in Chrome and Firefox and can even check permissions. It is a good thing as no one wants an app to get malicious stuff pushed to the clipboard. But Safari/Apple is even more restrictive: you can access this API via JavaScript in Safari only in a click event, only on a secure connection, etc. … :wink: - not always easy to get things work on all browsers.

Apple is becoming too restrictive, agreed.

But should a developer be concerned by clipboard on web?
For me, that’s just a way for the user to input text, like drag&drop or typing (in the context of web, I mean).

Well, I have business cases where it would be nice to push a result directly to the clipboard if you know that otherwise, the user has to copy it anyways, as all he needs is the result to be pasted somewhere else. In other words: if your app consists of publishing a result to an text area, and you know that your user will copy this content from the text area to another app, why not pushing it first hand into the clipboard ;-).

1 Like