The local information in each FileMaker file

Date settings in Europe and in the States, for example, are different.

The specification “01.10.2020” is interpreted in Europe as “October 1st, 2020”,
however, in the States as “January 10, 2020.”

In order that FileMaker knows how to understand a date specification, the local information is anchored as a fixed specification in the file when a file is created. On one hand, this allows an interpretation of the date, but should the file open later on another operating system, FileMaker can match new date entries (between system settings and the information anchored in the file). This ensures the integrity of various date entries.

Da es weltweit unterschiedliche Interpretationen von Datum und Uhrzeit gibt, verwaltet das Betriebssystem unterschiedliche Optionen. FileMaker puts the system settings for formatting (the local information) into the file as soon as it is created.

Regional settings

FileMaker sets a fixed point for interpreting the date, and this fixed point (or local information) does not change when the file is opened on a system with different date formatting. Internally, the fixed point remains, even if a date is entered differently due to a different operating system.

Example
If a FileMaker file is created in Europe, but then opened in the USA, the following situation occurs: Internally in the file the date interpretation was set to the European DAY/MONTH/YEAR. However, for the user in the USA, the system settings are MONTH/DAY/YEAR. In date fields this is no problem – FileMaker can adjust the display (!). Internally, however, the European structure remains intact. This can lead to problems.

Date calculations are unpredictable

There are problems with date calculations when the settings of the file are different from those of the user. Two sample files are included here as a download: It is the same file, but once as a file with European reference and once as a file with American reference. If you open a file, the following happens:

When you open the file that is not part of your system settings, the following happens: Dates written to text fields get the file-internal formatting (which is wrong). There are also problems with date calculations. The best way to see this is to open both files in parallel.

Neutral storage of dates

A date can be saved not only as a “date”, but also as a “date number”. FileMaker counts the days from January 1 of year 0001. Every date since then can therefore be represented as a number. This number is not dependent on any formatting. The date can thus be defined as numbers:

ReadAsNumber ( [DATE] )

To convert this number back to the date the following applies:

ReadAsDate ( [NUMBER] )

So with these two specifications dates can be stored neutrally, or transferred as a number from one file to the next. When converting back to a date, the date settings of this file then apply where it is interpreted.

Example
October 1, 2020 has the number “737699”. In a European file, it is converted to “01.10.2020”, while in an American file, the conversion is “10.01.2020”.

Removal of local information

The local information that FileMaker stores when creating a file cannot be modified. There is only one method to “reset” the file, namely by creating an empty clone of the file.

In the sample file there is a button with which such a clone can be created very easily. The local information of the file is reset when it is opened and therefore depends on the particular system that the user is using. The clone function makes it relatively easy to test the behavior in different system environments.

Program date neutrally

No FileMaker file today is neutral with respect to date processing. However, one can consider whether to aim for a neutral development of new solutions (with the help of the date number).

New features from FileMaker Pro 19.1

Claris has added two important features in the latest version:

• Get ( SystemLocaleElements)
• Get ( FileLocaleElements )

With these two functions you get a complete overview of all settings, nicely packed in JSON – once from the system and once from the file. From this, for example, the current data can be read out of the system and used for feedback, formatting or other purposes.

We are talking about system settings and file settings. Of course, programmed characteristics, such as language settings of a multilingual solution, are not considered.