Using Persistent Locale Data
A globalized application often persists or transmits data, for example, time and date. When deciding how your application should handle data persistence, remember that data is not guaranteed to be the same from computer to computer or between runs of the application. This is true for both locales that ship with Windows and custom locales.
Design of the application must take into account a variety of locale-related data changes that can occur. For example:
- Currency symbols can change as countries adopt the Euro.
- Regional preferences can change. For example, the format d/m/y might change to the format m/d/y for a particular locale.
- The spelling of day names can change due to spelling reforms. Additionally, casing can change for month or day names.
Use Locale-Independent Formats for Storage and Data Interchange
An application that persists data should use locale-independent formats for storage and data interchange. Examples are hard-coded or standard formats; the invariant locale LOCALE_NAME_INVARIANT; and binary storage formats.
If persistent sorting data is required, the application must use the CompareStringOrdinal function. Remember that an invariant format does not remain invariant for sorting, only for locale and calendar data.
Use the User Default Locale for Data Presentation
To present persistent data, it is best for the application to reformat the data using the user default locale. Use of this locale allows user overrides. For more information, see LOCALE_USER_DEFAULT.
Related topics