3

I need to make an application(D2006) independent of Regional Settings, most important all the dateformats must be the same.

For the beginning I want to replace all the FormatDateTime('adateformate') with FormatDateTime('aConstantDefined'). Also Application.UpdateFormatSettings and Application.UpdateMetricSettings should be set to False.

Is there anything else I should take/change?

LE: problem is that I have users with 2 different Regional Settings, and they don't want to uniform their settings. I know that sounds strange, but this is the fact. So, this is the reason why I need to make my application totally independent of Regional Settings.

Dominique
  • 16,450
  • 15
  • 56
  • 112
RBA
  • 12,337
  • 16
  • 79
  • 126
  • 1
    That's about it, but why do you want to ignore regional settings? It's not exactly kind to your users? – Marjan Venema Jan 09 '12 at 10:12
  • "independent of Regional Settings," you mean to say u want to ignore the local system date/time/decimal separator? – PresleyDias Jan 09 '12 at 10:36
  • @all - read my LE. Thank you. – RBA Jan 09 '12 at 10:39
  • 1
    I understand, but: their wishes are completely legitimate and you should not ignore the settings that they have chosen, especially not in the user interface. So you should actually use FormatDateTime with one of the "standard" settings strings (like "dddddd" to get a long date string). Going the other way (from a string to a date) you should use the StrToDate functions that can take a specific format and feed it the format as specified by the regional settings. – Marjan Venema Jan 09 '12 at 11:00
  • 3
    I think you are looking at this problem the wrong way. Users have good reasons for wanting to use regional settings that are typical for their regions. What you need to do is to respect those settings. You can achieve this by storing data in a single format defined by you. When you need to show output, use the prevailing regional settings to convert from the internal format to the format that the current user wishes to use. Likewise, when receiving input from the user, use the prevailing regional settings to convert to your private internal format. – David Heffernan Jan 09 '12 at 11:14
  • The bottom line is that you must not store anything (in memory, to files, to database) that is dependent on the regional settings of the current user. But you must use those settings when interacting with the user. – David Heffernan Jan 09 '12 at 11:15
  • Bumped into this same issue. Users may have an English operating system but they don't know how to change the regional settings, and they expect to see a comma as a decimal separator in the application; they will deem it as a bug if otherwise. Some controls (like JVCL numeric edits) will honor the regional settings; hence the need to change them for the application in my case. – Leonardo Herrera Nov 19 '12 at 03:11

1 Answers1

8

Apply your own TFormatSettings record. Call FormatDateTime('aConstantDefined',ADateTime,myFormatSettings) when appropriate.

This will avoid mishaps if your application changes the system format settings. So you don't have to use Application.UpdateFormatSettings and Application.UpdateMetricSettings.

Update :

I should add that all format string functions involved with regional settings, takes the TFormatSettings overloaded parameter. It is often used to make the application thread-safe, but comes in handy when overriding regional settings. I often use this technique when serializing/deserializing data for communication/storing purposes.

LU RD
  • 34,438
  • 5
  • 88
  • 296
  • As long as you manipulate your dates internally as `TDate` or `TDateTime` and not strings you should be pretty safe. The real problem is when you have different time zones! (Oh, money is also a hassle.) – Leonardo Herrera Jan 09 '12 at 13:17
  • 1
    @LeonardoHerrera, money is always a hassle :). Yes, keep data at their best format, and only do the necessary conversions during I/O. – LU RD Jan 09 '12 at 13:24
  • @LeonardoHerrera: you can store UTC date/time values in a `TDateTime` once you have adjusted the input by the local machine's timezone offset first. You can use the `TDateTime` normally for most operations as if the machine were running at UTC 0. Just make sure to take the local timezone into account whenever comparing to local timestamp values, converting back to string, etc. – Remy Lebeau Jan 09 '12 at 22:07
  • @RemyLebeau-TeamB - as I said, a hassle :-) – Leonardo Herrera Jan 10 '12 at 17:15