Implicit conversion problem with TDate type

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Implicit conversion problem with TDate type

Gabor Boros
Hi All,

I use MWA's IBX for Firebird connection and have problem with date
parameters. Tony provided to me a test program a suggested write to the
FPC list. The simple test program is:

program Project1;

uses Variants, Sysutils;

var V: variant;
     D: TDate;

begin
   D := EncodeDate(2016,10,20);
   V := D;
   writeln('date is ',VarType(D));
end.

The result is: "date is 5" (varDouble)

If modify D: TDate; to D: TDateTime; the result is "date is 7" (varDate)

I (We) missed something or is this a bug?

Gabor
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implicit conversion problem with TDate type

Michael Van Canneyt


On Wed, 2 Nov 2016, Gabor Boros wrote:

> Hi All,
>
> I use MWA's IBX for Firebird connection and have problem with date
> parameters. Tony provided to me a test program a suggested write to the FPC
> list. The simple test program is:
>
> program Project1;
>
> uses Variants, Sysutils;
>
> var V: variant;
>    D: TDate;
>
> begin
>  D := EncodeDate(2016,10,20);
>  V := D;
>  writeln('date is ',VarType(D));
> end.
>
> The result is: "date is 5" (varDouble)
>
> If modify D: TDate; to D: TDateTime; the result is "date is 7" (varDate)
>
> I (We) missed something or is this a bug?

Only TDateTime is automatically converted correctly to Variant.
TDate and TTime are distinct types and not automatically converted.
They are seen as doubles (the original type of TDateTime).

If Delphi prints another result, then we can look at fixing the implementation.


Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implicit conversion problem with TDate type

LacaK
Dňa 2.11.2016 o 11:38 Michael Van Canneyt napísal(a):

>
>
> On Wed, 2 Nov 2016, Gabor Boros wrote:
>
>> Hi All,
>>
>> I use MWA's IBX for Firebird connection and have problem with date
>> parameters. Tony provided to me a test program a suggested write to
>> the FPC list. The simple test program is:
>>
>> program Project1;
>>
>> uses Variants, Sysutils;
>>
>> var V: variant;
>>    D: TDate;
>>
>> begin
>>  D := EncodeDate(2016,10,20);
>>  V := D;
>>  writeln('date is ',VarType(D));
>> end.
>>
>> The result is: "date is 5" (varDouble)
>>
>> If modify D: TDate; to D: TDateTime; the result is "date is 7" (varDate)
>>
>> I (We) missed something or is this a bug?
>
> Only TDateTime is automatically converted correctly to Variant.
> TDate and TTime are distinct types and not automatically converted.
> They are seen as doubles (the original type of TDateTime).
>
> If Delphi prints another result, then we can look at fixing the
> implementation.
Delphi7 prints 5
Of course you can use V := TDateTime(D); then prints 7

-Laco.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implicit conversion problem with TDate type

Gabor Boros
In reply to this post by Michael Van Canneyt
2016. 11. 02. 11:38 keltezéssel, Michael Van Canneyt írta:
> If Delphi prints another result, then we can look at fixing the
> implementation.

With Delphi 10.1 and "D: TDate;" the result is "date is 5" and with "D:
TDateTime;" the result is "date is 7". So, the results are same with FPC
and Delphi.

Gabor
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implicit conversion problem with TDate type

Tony Whyman
It's an interesting concept i.e. if a bug exists in Delphi then it must
also exist in FPC. Perhaps a better alternative is to fix these sort of
bugs in FPC and  to introduce a "full Dephi compatibility mode" i.e.
mode Delphi plus the bugs.


On 02/11/16 11:04, Gabor Boros wrote:

> 2016. 11. 02. 11:38 keltezéssel, Michael Van Canneyt írta:
>> If Delphi prints another result, then we can look at fixing the
>> implementation.
>
> With Delphi 10.1 and "D: TDate;" the result is "date is 5" and with
> "D: TDateTime;" the result is "date is 7". So, the results are same
> with FPC and Delphi.
>
> Gabor
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implicit conversion problem with TDate type

Graeme Geldenhuys-6
On 2016-11-02 11:09, Tony Whyman wrote:
> It's an interesting concept i.e. if a bug exists in Delphi then it must
> also exist in FPC.

Yes I agree. FPC's Interfaces support suffer the same fate. eg: FPC's
CORBA style interfaces which Delphi doesn't have, implements the same
bugs as Delphi COM Interfaces???

I would prefer FPC to be bug free, no matter the compiler mode. If you
want bugs (and don't mind paying for them), stay with Delphi. If you
want a better compiler which is bug free, move to Free Pascal.

Regards,
  Graeme

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implicit conversion problem with TDate type

LacaK

>> It's an interesting concept i.e. if a bug exists in Delphi then it must
>> also exist in FPC.
> Yes I agree. FPC's Interfaces support suffer the same fate. eg: FPC's
> CORBA style interfaces which Delphi doesn't have, implements the same
> bugs as Delphi COM Interfaces???
>
> I would prefer FPC to be bug free, no matter the compiler mode. If you
> want bugs (and don't mind paying for them), stay with Delphi. If you
> want a better compiler which is bug free, move to Free Pascal.
>
> Regards,
>    Graeme
Probably handling TDate as TDateTime in FPC is adding:

operator :=(const source : TDate) dest : variant;{$ifdef
SYSTEMINLINE}inline;{$endif}
   begin
     VariantManager.VarFromTDateTime(Dest, TDateTime(Source));
   end;

in case of Delphi (at least 7) TDate is defined in Controls, so Variants
cann't depend on Controls.TDate ...

-Laco.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implicit conversion problem with TDate type

Jonas Maebe-2
In reply to this post by Tony Whyman
On 02/11/16 12:09, Tony Whyman wrote:
> It's an interesting concept i.e. if a bug exists in Delphi then it must
> also exist in FPC. Perhaps a better alternative is to fix these sort of
> bugs in FPC and  to introduce a "full Dephi compatibility mode" i.e.
> mode Delphi plus the bugs.

There is a difference between having a code construct that can be
compiled in one mode and not in another, and code that has different
behaviour in different modes. The former can be easily recognised, the
latter is much harder. In particular, it complicates reading code,
because you constantly have to be aware of the mode to know what the
code means. The same goes for changing behaviour across compiler
versions, and we have to do this way more often than I like.

Both of those things are symptoms of the worst possible situation you
can have in terms of code readability, while it is supposed to be one of
the focus points of Pascal.

We already have a few cases of code that compiles both in FPC and in
Delphi mode, such as this:

function func: longint;
begin
   func:=1;
   if func<>2 then
     writeln('ok');
end;

In FPC mode this writes 'ok'. In Delphi mode this causes endless
recursion. These are the worst kinds of gotchas, and most of them were
introduced in the early days of FPC when we indeed thought we would fix
everything that is wrong with TP. In the end, in many cases we just
introduced our own set of idiosyncrasies that you have to know about to
avoid getting bitten.

As Lacak mentioned, you can change the behaviour of this particular case
yourself if you want, without having to go over all existing code
written in FPC/ObjFPC mode to ensure that none of it relies on the
existing behaviour (assuming that this would be changed by adding the
extra operator Laco mentioned in a unit that would only be included in
programs compiled in FPC/ObjFPC mode).


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implicit conversion problem with TDate type

Tony Whyman
On 02/11/16 11:29, Jonas Maebe wrote:
On 02/11/16 12:09, Tony Whyman wrote:
It's an interesting concept i.e. if a bug exists in Delphi then it must
also exist in FPC. Perhaps a better alternative is to fix these sort of
bugs in FPC and  to introduce a "full Dephi compatibility mode" i.e.
mode Delphi plus the bugs.

There is a difference between having a code construct that can be compiled in one mode and not in another, and code that has different behaviour in different modes. The former can be easily recognised, the latter is much harder. In particular, it complicates reading code, because you constantly have to be aware of the mode to know what the code means. The same goes for changing behaviour across compiler versions, and we have to do this way more often than I like.
There was a certain amount of sarcasm in my comment that perhaps got lost in translation. I suggested introducing a "delphi with bugs" mode to illustrate the absurdity of the idea. My point is that why should FPC still feel constrained by Delphi? Let's get on and fix the bugs/features that Delphi should have fixed long ago.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implicit conversion problem with TDate type

Jonas Maebe-2
On 02/11/16 12:53, Tony Whyman wrote:
> There was a certain amount of sarcasm in my comment that perhaps got
> lost in translation. I suggested introducing a "delphi with bugs" mode
> to illustrate the absurdity of the idea. My point is that why should FPC
> still feel constrained by Delphi? Let's get on and fix the bugs/features
> that Delphi should have fixed long ago.

Please read my reply again. I was not talking about the downsides of a
hypothetical "delphi with bugs" mode. I was talking about the downsides
of changing the FPC/ObjFPC modes. I explained what the downsides would
be of doing so, even if the collective "us" would have the ability to
know in advance all of these changes' unintended consequences.


Jonas

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal