On Thu, 1 Mar 2007, Graeme Geldenhuys wrote:
> On 3/1/07, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> > > 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).
> >
> > You don't need to guess if it's in the database native format ?
>
> That wasn't our experience with MS SQL Server 2000 which uses the US
> date/time format even though the server was installed in the UK with
> UK regional settings. We had similar issues (can't remember exactly
> what) with Firebird. Hence the reason we now store it as strings.
I use Firebird.
Firebird stores date/time stamps as a 8-byte internal format.
The database engine returns you the value in this internal format,
so it's up to the database API to convert this to TDateTime.
When doing a query, i.e. in a SQL statement, you must indeed use
MM/DD/YYYY. If you use parametrized queries, you must use the
internal representation.
So there is no problem. You need exactly 2 routines:
TDateTime -> Firebird internal format.
Firebird internal format -> TDateTime.
These should normally be in your data access layer (FBLib, IBX, UIB, SQLDB)
so you don't need to code them yourself.
And if you really must hardcode dates in your queries, you need a third
function:
DateTime -> "MM/DD/YYYY"
Which you may need to code yourself.
That's it. No hassle, no problems. Works like a charm, and our applications
are used by thousands of users with the most diverse date/time settings.
As long as you stick to using and transmitting TDateTime consistently,
you should not have any problems. At least, that is my experience :-)
Michael.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
