I have a standalone Web app built with Xojo 2016r4, running on Ubuntu 16.04.1 on a VPS.
I’m in the UK, so to set the correct locale under Linux, I used the update-locale LANG=en_GB.utf8 command. I can verify that it’s taken effect correctly with the locale command. All looks good:
I’ve rebooted the VPS for good measure because, let’s face it, it’s always worth turning stuff off and back on again when there’s a problem
However, my Web app displays “short dates” with US date order - mm/dd/yyyy. I expected it to pick up the date format from the system, i.e. dd/mm/yyyy. I’ve found a thread dealing with a similar issue here: https://forum.xojo.com/23531-help-please-with-wrong-linux-date-format. However, in that case it was a CGI app rather than a standalone one as mine is, and the poster ended up working around the problem.
If I build the Web app for Windows, it works fine there, but I really want to have it hosted on Linux. Is there anything else I should be doing here? The Linux server is a VPS, so no problem to change system-wide settings as necessary.
Thanks Michel. Thing is, if I build the same Web app for the Windows platform and host it there, dates display correctly. And I’m using the same browser on the same computer to view the Linux-hosted and Windows-hosted versions of the Web app.
I checked the locale of the browser I’m using (Chrome on Windows) with chrome://chrome/settings/languages, and it’s reporting that it’s set to “English (United Kingdom)”.
I may be mistaken, then. Greg will probably chime in, but it looks like the program fetches locale from the computer and not the browser, as it should be IMHO.
Yes, I’ve got the VPS locale set to “en_GB.utf8” (see original post at the top for details on that). And the locale of Windows on the PC where my browser lives is also set to “English (United Kingdom)”.
Dynamic constants are loaded based on the browser locale.
Date formats are… well… tricky.
If you’re using the Date object from the Classic Framework, it should be taking the locale from the OS. Keep in mind that if the “user” has overridden the format of the dates, you’re out of luck.
If you’re using the New Xojo Framework, you’ve got more options. You can actually set a locale and have the dates come out in whatever locale you want by specifying the Locale parameter in ToText: http://developer.xojo.com/xojo-core-date$ToText
Thanks Greg. I am indeed using the Date object from the Classic Framework. The server’s system locale (as reported by Ubuntu’s “locale” command) is set to “en_GB.UTF-8”. If I run “set” at a shell prompt to list environment variables, everything looks fine there too. (LANG=en_GB.utf8 and LC_TIME=“en_GB.UTF-8”).
How does Xojo go about determining the system locale under Linux? If I knew that, perhaps I could make a tweak to one of the Linux config files so that Xojo picks it up correctly?
I ran some more tests. I built 3 versions of my Web app and spun up some Linux VMs to test them on. I made sure that the Linux VMs were set up with an “English (United Kingdom)” locale.
64-bit Linux build - hosted on the latest 64-bit version of CentOS.
32-bit Linux build - hosted on the latest 32-bit version of Linux Mint
64-bit Windows build - hosted on Windows 10 Pro 1607
Both of the Linux builds above exhibited the same date order problem as I got with 64-bit Ubuntu. But the version hosted on Windows worked fine.
In every case, the browser I used to connect to the Web app was Chrome on Windows 10.
Has anyone got a Web app built on the Classic Framework, hosted on Linux, that correctly displays dates in European date order (dd/mm/yyyy)? Could this be a bug in Xojo? I’m still really hoping there’s something I’m missing here!
You’re not missing anything, the Date class in the Classic Framework on Linux ignores locale entirely except when the date separator is “.” instead of “/”. You’d have to reformat your dates to the desired locale, or use the new Xojo.Core.Date class.
Thanks William. Is the date separator set at the Linux system level or the Xojo level? I’ve had a bit of a Google around, but don’t see a lot of info on that.
Michel - as a matter of interest, what do you do for dates in your Web apps? I know you do a lot of work with Web apps, and you’re in Europe, aren’t you?
Basically if we detect that the locale is using a “.” as the date separator we slightly adjust the output, but it’s still hard coded to something like DD.MM.YYYY
Thanks folks - it’s good to get definitive info on this. Will have a look at the “.” date separator option but I suspect I’ll either go with your suggestion of creating a little chunk of code to do the formatting as you suggest, Michel, or go with the New Framework option and check out the Locale class. Certainly neither alternative requires the application of large amounts of Rocket Science!
Public Function ConvertLongDate(all as String) as String
dim month, day, dayname, year as string
dayname = NthField(all, ",", 1)
month = NthField(all, ", ", 2)
month = NthField(month, " ", 1)
day = NthField(all, ", ", 2)
day = NthField(day, " ", 2)
day = NthField(day, ".", 1)
if left(day, 1) = "0" then day = right(day, 1)
year = right(all, 4)
return dayname + ", " + day + ". " + month + " " + year
End Function
dim d as new date
MsgBox (ConvertLongDate(d.LongDate))
A Canadian French speaking customer of mine specifically asked for DD MM YYYY.
My job is not to force people to use standards, but to offer customers what they request.
My app now offers any separator the user chooses, including no separator, YYYYMMDD, MMDDYYYY and DDMMYYYY. I love the ambiguity when both day and month are under 13. Cute.
Yes there are French speaking Canadians outside of Qubec, where Qubec standards do not apply. Also a number of people in Qubec still do not adopt the standard, mostly due to ignorance and resistance to change. I met the same resistance on several occasions. I show the OLF document to the client. In most cases, the client realizes that he must evolve. Some clients refuse. In the end, I do as you do. Internally however, when data is stored my apps always use ISO standards. It is then a question of formatting on the UI.
