> ----------
> From: Paul Heinz[SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 19, 1999 2:40:51 PM
> To: Multiple recipients of list delphi
> Subject: RE: [DUG]: Y2k issue
> Auto forwarded by a Rule
>
Hi, all.
> Found this problem with Delphi 2 and Delphi 3 ...
>
> Using a DBEdit or DBGrid to edit a date field, if you enter a
> year of '00',
> then it interprets this as meaning 1900. If after the year 2000 you enter
> '00' it interprets it as 2000 - i.e. it assumes current century.
>
> So, if in 2000 you edit a date field that refers to 1999 (e.g. change
> 10/5/99 to 11/5/99), then the year value will change to 2099!
>
> I imagine I'm not the first to come across this, but what is the general
> consensus on handling this? I've figured out a work around (other than
> going to 4 digit years) that involves a minor VCL tweak, but am curious to
> see what others have to say on this, and related, issues.
Yup. The root problem is in the Delphi 2 and 3 StrToDate routines which
TDateTimeField calls and their handling of 2 digit years. Real brain-dead
stuff, even in Delphi 4 they still throw 'bad date' exceptions at the drop
off a hat. (Don't get me started - it's a pet peeve).
Actually, I think Delphi 4 still has some Y2K issues if you don't enable
it's rolling window handling but maybe they default to having that enabled
now (finally!).
Without your own TField hierachy, you will be forced to patch the VCL or
muck with twiddling ShortDateFormat at run-time. I wrote my own family of
conversion routines (StrToFloat and company aren't much better than
StrToDate IMO) which handle all necessary Y2K issues, round consistently,
and are far more tolerant of user input, and our own TFields derivatives
(e.g. TnDateTimeField) use these instead.
TTFN,
Paul.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
