Locale on Linux set to "en_GB.utf8", but Web app date formats are US

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 :slight_smile:

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.

Unless I am mistaken, the web app bases its locale on the browser locale. Not the system host locale.

Often enough browsers are using en_US

See http://stackoverflow.com/questions/673905/best-way-to-determine-users-locale-within-browser#674570

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.

Have you tried to change the VPS locale ?

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)”.

[quote=302127:@Michel Bujardet]Unless I am mistaken, the web app bases its locale on the browser locale. Not the system host locale.

Often enough browsers are using en_US

See http://stackoverflow.com/questions/673905/best-way-to-determine-users-locale-within-browser#674570[/quote]
Well yes and no.

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?

Yes, I am in Europe.

But I did not need to localize my sites, as most of my business is in the US.

However, in my latest iOS app, I did need to have DDMMYYYY and to be able to change separator, since in Canada, they use space instead of /.

I simply created a small subroutine that generates the proper format according to the locale. It is not that difficult to do.

Just a matter of assembling a string from date.day, date.month and date.year, with separators.

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! :slight_smile:

The new framework has a locale option in the ToText method :

Will check that one out - not doing any iOS stuff yet, but it’s a good excuse to dip toes in with the New Framework.

The new framework has Locale for ToText with numbers as well. It is nice to format automatically with comma in countries where it replaces dot.

I use this method to get german date format

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))

The space part is correct, but the official date format in Qubec is YYYY MM DD. YYYYMMDD and YYYY-MM-DD are acceptable also.

Here is a link about the formats and conventions to be used in Qubec: http://www.oqlf.gouv.qc.ca/ressources/ti/dossiers/CCLQTI_20040720.pdf.
The English version of the document is here: http://www.oqlf.gouv.qc.ca/english/infoguides/cultural_ling_char_of_Quebec_IT_20061122.pdf.

The document is a bit dated, but essentially still correct.

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.

In the end “he who pays has the last word”.