Overrride locale dateformat settings

[juan.cristobo]

Hi all, the locale.dateformat on server is set to 'dd-MM-yyyy', but I like to override this setting for a client. How can I do it? I only see a 'getDefaultDateFormat', method, but not a 'setDateFormat'.

Regards,

[juan.cristobo]

Or is there an alternative? Our american users want to see date fields in us format, but spanish team want to see the fields in spanish format, and I don't know how to do it...

[jcompagner]

problem with the system settings that they are global, they are not client specific (they are in the servoy.properties)

The best thing todo currently is for those fields that need those dateformats, don't depend on the default value but set your value on the field (or columns level) and then use an i1i8n text instead of a direct format string
Then you can add format strings per language/locale

[Bernd.N]

We created first a valuelist like this:

d.M.yy 1.1.15|d.M.yy
d.M.yyyy 1.1.2015|d.M.yyyy
dd.MM.yy 31.12.15|dd.MM.yy
dd.MM.yyyy 31.12.2015|dd.MM.yyyy
dd-MM-yyyy 31-12-2015|dd-MM-yyyy
dd/MM/yyyy 31/12/2015|dd/MM/yyyy
MM/dd/yyyy 12/31/2015|MM/dd/yyyy
yyyy-MM-dd 2015-12-31|yyyy-MM-dd

Then every user has a date format field in his settings and user record, where he can choose the format he likes.
On startup, a global variable scopes.person.currentDateFormat_dd_mm_yyyy is set to that field.

In the onShow() of a form where a date is involved, we set the format of each date field like this:

Code: Select all

elements.ps_birthday.format = scopes.person.currentDateFormat_dd_mm_yyyy;

I do not know if there is a more easy method, but for us that works fine.
The only disadvantage is that in table forms, you first see another format for some milliseconds.

[Harjo]

Even a better idea is to loop over all your forms with solution Model find your datefields, and change them accordingly.
That is very fast, and no worry of doing it in onShow on every form.

[Bernd.N]

As far as I remember, we need to call that line always in onShow(), so we can not put it in an
if (firstShow)
because the date format used to switch back when we did it only in firstShow.

But in case the looping with solutionModel works fine and that problem will not appear, it would be even better.

[paronne]

Even a better idea is to loop over all your forms with solution Model find your datefields, and change them accordingly.
That is very fast, and no worry of doing it in onShow on every form.

Harjo you mean to do that at the onSolutionOpen ? the solution suggested by Johan has less overhead since there is no need to iterate over all forms/elements at startup.

[Harjo]

problem with the system settings that they are global, they are not client specific (they are in the servoy.properties)

The best thing todo currently is for those fields that need those dateformats, don't depend on the default value but set your value on the field (or columns level) and then use an i1i8n text instead of a direct format string
Then you can add format strings per language/locale

Hi Johan,

can you give an example? I'm not sure how you do that exactly

[paronne]

You can add an i18n key called mykeys.settings.dateformat with value "dd-MM-yyyy". On the format property of the field (or of the database column) you can then use i18n:mykeys.settings.dateformat. The format expression will then be evaluated as an i18n. So depending on your locale the i18n key for the dateformat may have a different value, therefore a different format is applied to the field.

[Harjo]

ah oke... thanks.
never knew that!

[Bernd.N]

May I add that language preference and date format preference of a single user is not necessary a one-to-one relation.
I have seen users who even prefer the ISO-8601-date format YYYY-MM-DD (like today 2016-05-10).

By decoupling the date format from the language, and by giving all users the ability to choose whatever they want in their UI, the users get maximum personal freedom for the date format.

Of course, the date format that will be printed on invoices etc. is another story, that is more specific to the company itself, but could be managed in a similar way.

[steve1376656734]

One way of achieving the decoupling of the date format from the language and using the user preference suggested by Bernd but also keeping the efficiency of using an i18n string suggested by Johan would be to use the following in your solution startup (before any forms have loaded):

Code: Select all

   if(scopes.person.currentDateFormat_dd_mm_yyyy)
      i18n.setI18NMessage('mykeys.settings.dateformat',  scopes.person.currentDateFormat_dd_mm_yyyy);


In this manner if the user has selected a personalised format then that will be used otherwise the default for their locale will be used.

Steve