Hi,
On 2/28/07, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
You should not have to worry about it. You use TDateTime, and convert to
string as needed as the user sees fit.
I don't agree with Graeme's solution: it's not up to the programmer
to decide how the date/time is shown to the user. The user has decided
that for us when he configured his regional/localization settings.
Both you and Peter V. misunderstood my post slightly. You don't have
to force the user to see the date/time in a certain format. Though we
opted for it after a length discussion. Storing the date/time as a
string in the ISO 8601 format is forced and allows you to export data
to another application without having to try and guess the date format
in the new application (yyyymmdd, ddmmyyyy, mmddyyyy, etc).
Once the string date/time is read and converted it to a TDateTime,
the GUI can displays it in the way the user specified in their
regional settings, but as soon as it goes back to the database or some
file, it gets converted back to the ISO string format.
So bottom line, the user sees the date/time it the format they prefer.
This is the first choice. We opted to follow the ISO
8601recommendation for display as well, to help remove confusion
between various date formats in digital or hardcopy form.
Imagine the following case:
The user in USA generates a report with date/time columns as a PDF
document. Emails that to head office in the EU somewhere where in
changes hands a few times. Now how do we know what date format that
report used?
Is 02-06-2002 the 2nd June or is it 6th Feb? So when is the deadline
for the multi-million dollar contract? :-) If it uses the ISO 8601
format yyyy-mm-dd there is no confusion, hence the reason we opted for
that format in our applications (display on screen and paper and in
storage).
--
Graeme Geldenhuys
There's no place like S34° 03.168' E018° 49.342'
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
