Just to add to this answer, there is an en localization that has the date in the US format. This can be changed by going into the Administration -> Localization -> Languages.
If Tryton was translated into en_IE (which it isn’t at the moment) I’m pretty sure it would use the date format from that Localization rather than the one defined for en.
Indeed you can just create a new language named “European English” or whatever you want an use the en_IE code for it. This will allow to set a diferent value for the “Date” format (and also other formats) while keeping the translations for the en format.
With this setup you can set diferent languages on each party so each one gets it’s correct format.
This is how we manage the Spanish language for Europe and Latin America.
I am working on version 5.4 and it works perfectly. I have version 5.4.20 installed on the server and the client version is 5.4.14, but 5.4.11 is also working.
But I have to say I installed some extra languages into the database so the user can choose which language to use instead of modifying existing values.
So I tried to change the date format of English to %d/%m/%Y and that worked as well and it kept working after restarting the server and client.
When you do a diff of tryton/common/datetime_.py from version 5.0 and 6.0 you don’t see a whole lot of differences rather then changing to GTK3. So I can imagine that this is a GTK issue fixed.
When I download 5.8.12 onto a Debian buster system and connect to the demo5.8 server, it does not work. Is anybody else able to reproduce this result from Debian or any other environment?
When I run 5.8.12 on the Debian system, do I need to adjust anything in the client code to make it use GTK3 on this platform? Or it always use GTK3 if available?
I also tried the diff on datetime_.py and there was no obvious clues. I was guessing that some other classes are not correctly interacting with the properties on the date fields.
It looks like the process is definitely using GTK3. This is tryton-client version 5.0.37, it exhibits the same bug, the database is configured for %d/%m/%Y but the dates appear with month first.
$ lsof -p 5623 | grep -i gtk
python3 5623 daniel mem REG 253,2 26624 1059763 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-wayland.so
python3 5623 daniel mem REG 253,2 7251000 1059773 /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.1
python3 5623 daniel mem REG 253,2 194182 1101333 /usr/share/locale/en_GB/LC_MESSAGES/gtk30-properties.mo
python3 5623 daniel mem REG 253,2 103610 1101334 /usr/share/locale/en_GB/LC_MESSAGES/gtk30.mo
python3 5623 daniel mem REG 253,2 676312 1074049 /usr/lib/x86_64-linux-gnu/girepository-1.0/Gtk-3.0.typelib
python3 5623 daniel mem REG 253,2 3263 133332 /usr/share/locale/en/LC_MESSAGES/gtk30.mo
python3 5623 daniel mem REG 253,2 367 133330 /usr/share/locale/en/LC_MESSAGES/gtk30-properties.mo
I tested on 5.0 series with the demo server and I can not reproduce. The only case where the format was not changed is because the user was not linked to any language so it use the client system format which is expected.
Thanks, that is a useful tip. In this case, I was using the admin account to evaluate Tryton. The admin account is created by default without specifying a language.
After setting the language for admin to English the dates are displayed correctly.
On the test system, other applications are always using %d/%m/%Y. In fact, when Tryton creates an invoice it also has the date in the correct format. This is the environment:
another thing that comes to mind: why did it work for me with the 6.0 client? In demo6.0 the admin user does not have any language in the preferences. Therefore, there is some code change between 5.8 and 6.0 that makes it work in 6.0
Here is some more feedback from Python, it looks like Python doesn’t do the right thing for en_GB.UTF-8:
$ python3
Python 3.7.3 (default, Jan 22 2021, 20:04:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getlocale()
('en_GB', 'UTF-8')
>>> import datetime
>>> x = datetime.datetime.now()
>>> print(x.strftime("%x"))
08/07/21
>>>
That is m=8/d=7/y=21 - I would expect 7/8/21 in the UK