...

i18n.setI18NMessage('servoy.lbl.date', utils.stringReplace(i18n.getI18NMessage('servoy.lbl.date'),'/','-'))

...

Separators

Formatting defaults need to be specified. In the English(US) format, the dot ('.') is decimal separator (and comma is 1000 separator). Decimal values within code need to be specified in English format as well. This will automatically be translated to the end users format when they run the code.

...

Localized Formatting

Servoy allows setting supports locale formats on numbers, integers, and dates.

There are four levels of setting the locale format:

1. Java Virtual Machine (JVM) level - setting the locale language, country and (optional) variant Java arguments. This will determine the formats used by the Servoy Clients.
   Since multiple countries may speak the same language, but the number/date formats are different from one country to another, the country argument is needed to ensure precision to the formats used by the application.
   Example This is an example of setting the locales for Germany, with specific for Macintosh platforms.

   Code Block
   -Duser.language=de -Duser.country=DE -Duser.variant=MAC

   A number format used by Servoy will therefore be: 123.456,789
   See more information on Oracle's page Internationalization: Understanding Locale in the Java Platform.

2. Servoy Application Server level - setting the Locale Settings on the

...

1. Servoy Server Home page; the formats set will be applied to all fields that do not have a format set at table or field level

...

1. .
   2.1. The Smart Client's locale formats can be also set via Edit > Preferences > Locale; the formats set in this way will be applied on top of the Admin Page settings.
2. table level - setting the Default format under Details tab on a column, in the Table Editor; the format set will be applied to all fields having the column as data provider, that do not have a format set on field level.
3. field level - setting the format property of a field in Properties view.

Timezones

In JavaScript (and Java), dates are always timestamps with the number of milliseconds which have passed since January 1st 1970 in UTC. Only when a date is displayed or converted to a string, the conversion to a certain timezone is done.

Example
If one calls application.getTimeStamp() at 8pm in Colombo, Sri Lanka and at 8pm in LA, California USA, two different timestamp values will be received. On the other hand, if two developers, one located in LA and one in Colombo would execute the code at exactly the same time, they would get exactly the same timestamp value, regardless of the timezone they are in.

The Servoy Application Server can be forced to run in a certain timezone, by including the following JVM argument in command line:

-Duser.timezone=US/Eastern

A complete table with the supported values of the timezone property can be found on IBM's WebSphere Application Server page.

For NGClient solutions, use the format property (Use as LocalDateTime checkbox) per field to dictated if the timezone should be used in client or not.
For the old web clients and smart clients, Servoy has 2 modes for working with Timezones. Switching between these two modes can be done by toggling the servoy.use.client.timezone property on the Servoy Application Server's Servoy Server Home page, under Locale Settings.
Take note, that this setting is ignored by the NGClient solutions.

Property set to true:

A datetime entered will be presented exactly the same in each client, regardless of the timezone of the client 

Example: Any client, regardless of which timezone they are in, sees a datetime entered as 8pm as 8pm. Servoy makes corrections under the hood to achieve this.  (like birthday)

Property set to false:

Servoy performs no calculation and the dates are automatically converted by Java to match the user's timezone. 

Example: A client in UTC + 5 enters 10pm. The server runs in UTC, so stores 5pm. And a client in UTC - 2 sees 3pm. Since databases do not store a timezone with a date, everything will be mixed up when the database is started in another timezone.

The first scenario (having client timezone property set to true) is the preferred way of operating, because this gives the most consistent outcome. (like calendar item)

So For NGClient checking the "Use as LocalDateTime" property has the same affect as the property set to true above but just for that dataprovider