Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2014-05

StrToDate bug?

11 messages · 5 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Bart

Hi,

I'm using fpc 2.6.4.

While i was playing a bit with issue
http://bugs.freepascal.org/view.php?id=20522 I stmbled upon unexpected behaviour of StrToDate function.

StrToDate('6-12-2011 ') (note the space at the end) actually gives me 6-12-2014.

=======================
program stodate;
{$mode objfpc}{$H+}
//{$mode delphi} behaves the same
uses
  Classes, SysUtils;
procedure TestStrToDate(DS: String);
var
  FS: TFormatSettings;
  DT: TDateTime;
  RetS: String;
begin
  FS := DefaultFormatSettings;
  FS.ShortDateFormat := 'd-M-yyyy';
  FS.LongDateFormat := 'dddd d MMMM yyyy';
  FS.DateSeparator := '-';
  if TryStrToDate(DS, DT, FS.ShortDateFormat, FS.DateSeparator) then
  begin
    RetS := DateToStr(DT, FS);
    write('"',DS,'" -> "',RetS,'"');
    if Trim(DS)  RetS then writeln('  ?') else writeln;
  end;
end;
procedure RunTestStrToDate;
begin
  TestStrToDate('6-12-2011');
  TestStrToDate('6-12-2011 ');
  TestStrToDate('6-12-2011  ');
  TestStrToDate('6-12-2011   ');
end;
begin
  RunTestStrToDate;
end.
================

Output with fpc 2.6.4
"6-12-2011" -> "6-12-2011"
"6-12-2011 " -> "6-12-2014" ?
"6-12-2011 " -> "6-12-2014" ?
"6-12-2011 " -> "6-12-2014" ?

Output with Delphi7
"6-12-2011" -> "6-12-2011"
"6-12-2011 " -> "6-12-2011"
"6-12-2011 " -> "6-12-2011"
"6-12-2011 " -> "6-12-2011"

Could somebody test this with trunk to see if this has already been fixed?

Bart

Martin Frb
to Bart
Bart wrote 9 lines
Hi, I'm using fpc 2.6.4. While i was playing a bit with issue http://bugs.freepascal.org/view.php?id=20522 I stmbled upon unexpected behaviour of StrToDate function. StrToDate('6-12-2011 ') (note the space at the end) actually gives me 6-12-2014.

...

Could somebody test this with trunk to see if this has already been fixed?

Same, with trunk (checked out from yesterday)

Michael Van Canneyt
to Bart: I'm using fpc 2.6.4. While i was playing a bit with issue…
Bart wrote 9 lines
Hi, I'm using fpc 2.6.4. While i was playing a bit with issue http://bugs.freepascal.org/view.php?id=20522 I stmbled upon unexpected behaviour of StrToDate function. StrToDate('6-12-2011 ') (note the space at the end) actually gives me 6-12-2014.

That is because the last part is not 'correct' (contains trailing garbage) and then the strtodate assumes the year is missing, and substitutes the current year, as if you had specified 6-12.

It still functions like this in trunk.

A simple trim() will solve this, presumably.

Michael.

Bart
to Michael Van Canneyt
Michael Van Canneyt wrote 10 lines
> StrToDate('6-12-2011 ') (note the space at the end) actually gives me > 6-12-2014. That is because the last part is not 'correct' (contains trailing garbage) and then the strtodate assumes the year is missing, and substitutes the current year, as if you had specified 6-12. It still functions like this in trunk.

I'll open a ticket for it in bugtracker then.

Bart

Michael Van Canneyt
to Bart
Bart wrote 14 lines
On 5/10/14, Michael Van Canneyt wrote: >> StrToDate('6-12-2011 ') (note the space at the end) actually gives me >> 6-12-2014. > > That is because the last part is not 'correct' (contains trailing garbage) > and > then the strtodate assumes the year is missing, and substitutes the current > year, > as if you had specified 6-12. > > It still functions like this in trunk. I'll open a ticket for it in bugtracker then.

Fixed.

Michael.

Bart
to Michael Van Canneyt
Michael Van Canneyt wrote
Fixed.

You fixed it faste then it took me to type the bugreport! I cannot test with trunk, so feel free to close the issue in the bugtracker.

B.t.w. I could not find an entry in "Product version" for 2.6.4 (or 2.7.1 for that matter).
Where should I report this?

Bart

Michael Van Canneyt
to Bart
Bart wrote 6 lines
On 5/10/14, Michael Van Canneyt wrote: > Fixed. You fixed it faste then it took me to type the bugreport! I cannot test with trunk, so feel free to close the issue in the bugtracker.

Will do, thanks.

B.t.w. I could not find an entry in "Product version" for 2.6.4 (or 2.7.1 for that matter). Where should I report this?

You should not. There is a version 2.6.4, I added a version 'trunk'. To avoid having to re-create each trunk version.

Michael.

Sven Barth
to Michael Van Canneyt
Michael Van Canneyt wrote 7 lines
> > B.t.w. I could not find an entry in "Product version" for 2.6.4 (or > 2.7.1 for that matter). > Where should I report this? You should not. There is a version 2.6.4, I added a version 'trunk'. To avoid having to re-create each trunk version.

I believe it was intentional that we didn't have a "trunk" version. At least that's what I rememeber...

Regards,
Sven

Michael Van Canneyt
to Sven Barth
Sven Barth wrote 11 lines
On 10.05.2014 16:20, Michael Van Canneyt wrote: >> >> B.t.w. I could not find an entry in "Product version" for 2.6.4 (or >> 2.7.1 for that matter). >> Where should I report this? > > You should not. There is a version 2.6.4, I added a version 'trunk'. > To avoid having to re-create each trunk version. I believe it was intentional that we didn't have a "trunk" version. At least that's what I rememeber...

Yes, in hindsight a bad idea. I removed it meanwhile.

Michael.

Jonas Maebe
to Michael Van Canneyt: Will do, thanks. You should not. There is a version 2.6.4, I added a version 'trunk'. To…
Michael Van Canneyt wrote
You should not. There is a version 2.6.4, I added a version 'trunk'. To avoid having to re-create each trunk version.

I don't think that is good. It will make it much harder to determine which trunk version the bug report is about. It makes it also more difficult for non-experienced users (and thanks to binary snapshots, many of those use trunk versions), because the compiler prints "2.5.1" or "2.7.1" as version number, never "trunk". Also, once 2.8.0/3.0.0 is released, right now with a single SQL command we can change the "fixed in version" field for all 2.7.1 bugs to that version. That's impossible if you work with a generic moniker like trunk.

Jonas