I agree that when you can you should use TDateTime but there are cases where string presentation for storage is needed. Lets say we make a export / import function in a CSV file.
There needs to be a contract on how to store dates (and numbers for that sake) that is the same. Displaying to me is best left to the operating system. Now with that date as a string in to the database this can still be a advantage. Like for systems that don't always know the exact day. By representing them in String this can be overcome. Searches can be done on year and month fairly easy. Met vriendelijke groet, Pieter Valentijn Delphidreams http://www.delphidreams.nl -----Oorspronkelijk bericht----- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Michael Van Canneyt Verzonden: woensdag 28 februari 2007 22:49 Aan: [email protected] Onderwerp: RE: [lazarus] StrToDate error 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: [email protected] > 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 _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
