On Wed, 28 Feb 2007, Pieter Valentijn wrote:

> Most users here will find this kind of display confusing.
> But I agree with the store path. Anny external storae that needs sting
> presentation should be in one format or at least s format agreed on. The
> case I have is that variants are used in parce thechnieks and there
> cnversion is importamt to the rules. (reporting uses parces and so you
> need to go from string to date and from date to string using variants.
> Im not sure how this is aranged in Laz but I think in Delphi its not
> realy working well.

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.

To be able to store date/times without worrying about the settings, the
TDateTime format is used. It's the responsability of the data layer to
convert TDateTime correctly to/from something the database understands.

It's the responsability of the GUI layer to display the TDateTime 
to the user in the format HE specified. And to convert anything HE
provides to TDateTime format.

I've been working for 10 years with this principle, in databases which
are crowded with date/time fields (the number of fields runs in the 1000s)
and the only problem we ever experienced was when we explicitly converted
TDateTime to string representation using some wrong string. We don't use
custom routines, only the standard Delphi routines.

The previous version of the same application, written in VB, was crowded
with problems exactly because the dates were manipulated as strings instead
of as some native date/time format such as TDateTime.

So IMHO Delphi handles it pretty well. But you must stick to the rules it 
and the user set...

Michael.

> 
> 
> 
> Met vriendelijke groet, 
> Pieter Valentijn
>  
> Delphidreams
> http://www.delphidreams.nl
>  
> 
> 
> -----Oorspronkelijk bericht-----
> Van: Graeme Geldenhuys [mailto:[EMAIL PROTECTED] 
> Verzonden: dinsdag 27 februari 2007 7:48
> Aan: lazarus@miraclec.com
> Onderwerp: Re: [lazarus] StrToDate error
> 
> 
> I didn't follow the full thread, so excuse me if this reply is out of
> context. Have you guys ever considered using the International ISO 8601
> date format. See the following link for a summary:
> 
>   { Summary of ISO 8601  http://www.cl.cam.ac.uk/~mgk25/iso-time.html }
>   cIntlDateTimeStor = 'yyyymmdd"T"hhmmss';    // for storage
>   cIntlDateTimeDisp = 'yyyy-mm-dd hh:mm:ss';  // for display
> 
> 
> I've also created a few helper functions that convert those date formats
> to TDateTime, and the reverse.
> 
>   function tiDateTimeAsIntlDateStor(const ADateTime: TDateTime): string;
>   function tiDateTimeAsIntlDateDisp(const ADateTime: TDateTime): string;
>   function tiIntlDateStorAsDateTime(const AValue: string): TDateTime;
>   function tiIntlDateDispAsDateTime(const AValue: string): TDateTime;
> 
> Once it's in a TDateTime, any GUI date/time edit component can do with
> it as it pleases, though I still show it in the ISO display format. Even
> for storing dates in a database, I don't use the DB's native date/time
> types, I rather use the ISO storage format and a plain string field.
> This way I always know the date formats and no confusion with date/time
> delimiters and no confusion with the date parts order d/m/y, y/md/,
> m/d/y, etc...
> 
> I've been using this in a production environment for over a year now
> without any issues.
> 
> Regards,
>   - Graeme -
> 
> 
> 
> On 2/27/07, Pieter Valentijn <[EMAIL PROTECTED]> wrote:
> > I tend to have trouble with variants.
> > If I use this techniek and I store a date string in a variant it does 
> > not want to convert to date. So I want to stick to the sys locale and 
> > make sure i don't try to swim upstream :-)
> >
> > Met vriendelijke groet,
> > Pieter Valentijn
> >
> > Delphidreams
> > http://www.delphidreams.nl
> >
> >
> >
> 
> _________________________________________________________________
>      To unsubscribe: mail [EMAIL PROTECTED] with
>                 "unsubscribe" as the Subject
>    archives at http://www.lazarus.freepascal.org/mailarchives
> 
> _________________________________________________________________
>      To unsubscribe: mail [EMAIL PROTECTED] with
>                 "unsubscribe" as the Subject
>    archives at http://www.lazarus.freepascal.org/mailarchives
> 

_________________________________________________________________
     To unsubscribe: mail [EMAIL PROTECTED] with
                "unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Reply via email to