You're right. Print is not the problem. Another part of Gambas could
raise an error. But Benoit is right. Doing this kind of check is too
resource intensive. You're also right. Since DateDiff(gb.second) will
overflow for a ~70 year difference, over the longer term, it should
return a long
Toni,
I don't think Print is at fault here at all. My guess is that DateDiff may need
an "attitude adjustment" in these cases: It may need to either raise an
overflow error or return a 64bit Long.
Hope this helps,
zxMarce.
On Aug 6, 2017, 12:00, at 12:00, Tony Morehen wrote:
>zxMarce, you a
zxMarce, you are exactly right. DateDiff returns an integer so when
print adds the two datediff it adds 2 signed integers and gets an signed
integer. Since the max value of a signed integer is 2147483647, the
answer of 2208988800 overflows to -2085978496. So print's behaviour is
as expected.
Without a machine nearby, I'd risk you're in the right track.
The DIM AS LONG creates 64bit vars while DateDiff may return 32bit data (don't
have the docs with me).
Print will use 64bit to print the vars and 32bit with direct DateDiff (you may
confirm by using CLng to affect the DateDiff's in t
Hello,
Why are two different results:
Public Sub Main()
Dim a, b As Long
a = DateDiff("01/01/1900", "01/01/1935", gb.Second)
b = DateDiff("01/01/1935", "01/01/1970 ", gb.Second)
Print a + b
Print DateDiff("01/01/1900", "01/01/1935", gb.Second) +
DateDiff("01/01/1935", "01/01/1970 ",
