Date format is wrong

I’m using the Debian package of Tryton v5.0.5-1

My system has a European locale

LANG=en_IE.UTF-8
LC_TIME=en_IE

In the user interface, the dates appear in the US format, e.g. 05/31/2021 while I would expect to see the day before the month, e.g. 31/05/2021

The client uses the date format defined on the language of trytond.

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.

1 Like

I went into Administration -> Localization -> Languages -> English

I changed the date format to %d/%m/%Y

The Invoice document in LibreOffice now shows the date in the d/m/y format

The tryton-client GUI still shows incorrect (US) m/d/y dates

I exited the GUI and opened it again and it is still the same, m/d/y

Is there anything else I need to do to make the GUI show the correct date format?

I’m using the 5.0 packages on Debian buster.

Use a recent version before reporting issue.

I downloaded the 6.0.4 tarball, unpacked it and connected to demo6.0.tryton.org

I went to Administration, Localization, Languages, English and found it was using %m/%d/%Y

I replaced that with %d/%m/%Y and clicked Save

Then I went to look at the Fiscal Year start and end dates. The end date is 12/31/2021.

I logged out of the client and started it again. After logging in again, I look at the Fiscal Year start and end dates. The end date is 31/12/2021.

On 5.0.4 the invoices printed with LibreOffice have the correct date format. The problem is only in the desktop GUI date fields.

Does anybody know what change in the desktop client between 5.0.4 and 6.0.4 has fixed this issue?

Could the desktop client display a warning when somebody changes a setting that requires a restart like this?

Could anybody clarify the language = value in trytond.conf?

Is that value selecting one of the entries defined in the table that appears at Administration/Localization/Languages?

Or is that value selecting one of the values from locale -a?

Or does it need to be valid in both places?

Or something else?

I tried a few other versions:

Tryton client 6.0.0: the date appears correctly

Tryton client 5.8.12: the date is always m/d/Y, even after a restart

Therefore, it looks like the bug was fixed between 5.8.12 and 6.0.0. Does anybody know the reason it works now?

I put this in the bug tracker
https://bugs.tryton.org/issue10615

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:

$ locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

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

You must call locale.setlocal(locale.LC_ALL, '') to load the locale definition in python.
The tryton client does it for you.

Here is the output on the system where I run the client:

$ 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.setlocale(locale.LC_ALL, '')
'en_GB.UTF-8'
>>> locale.getlocale()
('en_GB', 'UTF-8')
>>> import datetime
>>> x = datetime.datetime.now()
>>> print(x.strftime("%x"))
09/08/21

Therefore, using locale.setlocale appears to fix the output

Why is this working in 6.x but not in 5.8.x? Was this call to locale.setlocale(...) only added in 6.x?