[fpc-pascal] Why has StrToDate() failing under FPC 2.3.1 (64bit)

[Michael Van Canneyt]

On Tue, 20 Oct 2009, Graeme Geldenhuys wrote:

> On 20/10/2009, Michael Van Canneyt <michael at freepascal.org> wrote:
>> -----------------------------------------------------------------
>>  Call StrToDate to parse a string that specifies a date. If S does
>
> [...]
>
>
>>  First lines say it all. "dd/mm/yyy hh:nn" is not supposed to work.
>
> That's up for discussion! :-) It says the string must specify a date.
> It does not say it must ONLY specify a date. It parses the string from
> the left extracting what it needs, once it has all required
> information to build a date, it ignores the rest.

I'll adapt the docs and insert the 'only'.

>
> Also, do I specify a date from the 17th century? Does StrToDate()
> limit itself forever to only assume 19xx & 20xxx dates?
>
> Why does StrToDate() use the ShortDateFormat - didn't we learn our
> lesson with the Y2K bug?

Y2K is not relevant. 
My ShortDateFormat is set to dd/mm/yyyy, perfectly Y2K safe.

Only the relative order of y,m,d is needed from shortdateformat.
So the actual number, 1,2 or 4 ys is not relevant. You are still thinking
that it uses the actual dateformat, when it does not.

> PS:
> Oh and a nice hidden little features (I couldn't find documentation
> for). When you specify a date format as 'yyyy/mm/dd' or dd/mm/yy
> etc... The '/' character is NOT the separator! The '/' in that
> formatting string means the separator specified by the global
> DateSeparator variable.

Ehm. This is so since day 1, it's even documented ?

>
> Yet if you specify 'yyyy-mm-dd', then the '-' character IS the date
> separator to use, ignoring global DateSeparator variable.
>
> Maybe the FPC docs could be extended to include this little gem. By
> the way, I tested the above theory with Kylix 3 and Delphi 7.

It is mentioned in topic 'Date and time formatting characters' of the FPC
docs.

Michael.