Got a very weird issue with an app originally migrated from DE6.53 on both DE8.5 and LE9.

The updated app must be setup for a client with a different regional date setting.

Normally if the regional date format changes then DE will automatically use the new Windows regional settings date format.

The original regional short date setup is YY/MM/DD ; long date YYYY/MM//DD.

The new short date setup in Windows regional settings is DD/MM/YY ; long date DD/MM/YYYY.

For the migrated app any forms with date fields retain the original YY/MM/DD.

Note that this is not and issue with old existing data. The migrated app installation is stripped of data. 

The date field hint in Designer view show the date fields with the original YY/MM/DD format despite being on a server with regional settings short date format DD/MM/YY.

Even if a new form is created in the app the date fields default to the original YY/MM/DD.

If a new app is created on the same server, then date fields have the expected format - DD/MM/YY .

What is causing the migrated app (DE8.5 & LE9) to retain the original location date format YY/MM/DD independent of the Windows regional settings DD/MM/YY?

Got it sorted.
Was an issue with the Configuration DBM.
Replaced it and date format is now as expected

Glad you got it fixed.

There is some recurring "challenges" over the years in DataEase like Sequence Numbers etc. And obviously Date is also one of these.

Originally this was decided by DataEase i.e. what you set in your Configuration file/how DataEase was set up with nice additions to the challenge with things in ZTERMDEF, CONFIGUR.DAT, PRISM.INI etc. 

At some stage in DE6/DFD 5 it was temporarily decided that the Windows version should decide the stored format in DataEase.

When one look inside the code of DataEase one find that the same problem has been solved many times in very different ways simply because many different teams have worked on the product without the hand over being "exhaustive". 

A lot of things that the DataEase "community" has wanted has been almost completed in the code and then abandoned for reasons only the "dead" will be able to answer.

One of these easter eggs is the problem with Date formats in DFW 6/DFD5. We find that migrating DFD 6 mostly works if one "pretend" the application is American and then fix the date problem after migration.