# Problem with Date.TotalSeconds on Raspberry Pi

In trying to debug a problem I’m having with Date arithmetic I wrote the following test code as a console app.

Dim i As Integer
Dim d As Date
d = New Date
Dim z As Double = d.TotalSeconds

For i=1 To 10
z = z*10
d.TotalSeconds = d.TotalSeconds * 10
Print("Z: " + Str(z) + " TS: " + Str(d.TotalSeconds))
Next

When I run it on a Mac I get the expected output as follows:

Z: 3.691069e+10 TS: 3.691069e+10
Z: 3.691069e+11 TS: 3.691069e+11
Z: 3.691069e+12 TS: 3.691069e+12
Z: 3.691069e+13 TS: 3.691069e+13
Z: 3.691069e+14 TS: 3.691069e+14
Z: 3.691069e+15 TS: 3.691069e+15
Z: 3.691069e+16 TS: 3.691069e+16
Z: 3.691069e+17 TS: 3.691069e+17
Z: 3.691069e+18 TS: 3.691069e+18
Z: 3.691069e+19 TS: 3.691069e+19

However, when run on the raspberry Pi I get:

Z: 3.691069e+10 TS: 3.691071e+10
Z: 3.691069e+11 TS: 3.691070e+11
Z: 3.691069e+12 TS: 3.691070e+12
Z: 3.691069e+13 TS: 3.691070e+13
Z: 3.691069e+14 TS: -6.005307e+10
Z: 3.691069e+15 TS: -6.005303e+10
Z: 3.691069e+16 TS: -6.005303e+10
Z: 3.691069e+17 TS: -6.005303e+10
Z: 3.691069e+18 TS: -6.005303e+10
Z: 3.691069e+19 TS: -6.005303e+10

Any ideas or is this a bug?

Peter

Our raspberry pi framework is 32-bit whereas the Mac framework is 64-bit. That’s probably just an overflow situation.

It would be helpful if you would also print d.sqldatetime there.

Greg,

Thanks for the reply. At first I assumed it was an overflow but it seems to occur well before the 32-bit float upper limit. Also, it is only happening with the totalseconds property but not the Double variable z.

I will investigate the SQL property and get back to you tomorrow - it’s almost midnight here.

remember that unsigned integers only go up to 2^31

You clearly see the scientific markers. Output:
-60053030000

Perhaps the there is something else wrong…

Could it be your timezone is different?

Perhaps try DateTime that should work better. And try to use .ToString instead of Str()

Xojo documentation says that TotalSeconds is a Double so, even if it’s a 32-bit double it shouldn’t overflow until around 10^38 but in the example above it seems to happen at around 10^14.

I’ve added SQLDateTime to the print out and it seems to fail even on the Mac.

Z: 3.691143e+10 TS: 3.691143e+10 SQL: 3073-09-03 13:59:10
Z: 3.691143e+11 TS: 3.691143e+11 SQL: 13600-10-05 19:51:40
Z: 3.691143e+12 TS: 3.691143e+12 SQL: 118871-08-26 06:36:40
Z: 3.691143e+13 TS: 3.691143e+13 SQL: 1171580-07-14 18:06:40
Z: 3.691143e+14 TS: 3.691143e+14 SQL: 5828963-12-20 00:00:00
Z: 3.691143e+15 TS: 3.691143e+15 SQL: 5828963-12-20 00:00:00
Z: 3.691143e+16 TS: 3.691143e+16 SQL: 5828963-12-20 00:00:00
Z: 3.691143e+17 TS: 3.691143e+17 SQL: 5828963-12-20 00:00:00
Z: 3.691143e+18 TS: 3.691143e+18 SQL: 5828963-12-20 00:00:00
Z: 3.691143e+19 TS: 3.691143e+19 SQL: 5828963-12-20 00:00:00

I guess dates have a limit. Just for testing I used DateTime and instead d.TotalSeconds I used d.SecondsFrom1970, here is the result:

`Z: 1.608267e+10 TS: 1.608267e+10 SQL: 2479-08-21 18:35:14`
`Z: 1.608267e+11 TS: 1.608267e+11 SQL: 7066-05-24 14:52:25`
`Z: 1.608267e+12 TS: 1.608267e+12 SQL: 52933-12-11 00:44:13`
`Z: 1.608267e+13 TS: 1.608267e+13 SQL: 511609-06-09 14:22:14`
`Z: 1.608267e+14 TS: 1.608267e+14 SQL: 5098364-05-22 20:42:26`
`Z: 1.608267e+15 TS: 1.608267e+15 SQL: `
`Z: 1.608267e+16 TS: 1.608267e+16 SQL: `
`Z: 1.608267e+17 TS: 1.608267e+17 SQL: `
`Z: 1.608267e+18 TS: 1.608267e+18 SQL: `
`Z: 1.608267e+19 TS: 1.608267e+19 SQL: `

It looks like after a certain number of seconds the SQLDateTime can’t handle the conversion.

Interesting that this code:

``````Dim d1 As DateTime = DateTime.FromString("144683-12-31 23:59:59")
Dim d2 As DateTime = DateTime.FromString("144684-01-01 00:00:00")
``````

the first line works and the second line shows a RunTimeException with the legend: Parse error: date needs to be in the format of YYYY-MM-DD HH:MM or YYYY-MM-DD

Just out of curiosity, why does the year 5828963 matter to you anyway?

1 Like

I wondered when someone would ask.
I’m putting together a simple web app that calculates time dilations in special relativity for an object travelling close to the speed of light. As the speed goes up the dilation becomes extreme. Below is some sample output from the app and, as you can see, the date calculation is wrong.

I think I’m just asking too much of date arithmetic from what is essentially a commercial development environment. I think I will need to develop my own algorithms or just refer to time periods rather than specific dates.

For timescales above year 9999 you should deploy your own date/time math. Things get insecure above YYYY.

Yeah, I think you’re right. In theory there’s no reason it shouldn’t work for later dates (until overflows become a problem) but it’s unlikely that beta testers are going to trap errors beyond dates in the immediate future.

1 Like

Does it make any difference if you use

d.TotalSeconds = d.TotalSeconds * 10.0

No, that doesn’t make a difference. The problem might be a bug or it might just be some internal overflow - although it’s not immediately obvious to me why adding to a double variable works but not the double property of a date. Perhaps the overflow happens as part of the set method of that property.

It’s a bit annoying but, to be honest, I’m probably the only Xojo user on the planet who’s annoyed that date arithmetic fails when applied thousands of millennia into the future so, even if it is a bug, I reckon it’s going to be right down on the bottom of the dev team’s list of nagging issues that keeps them up at night - and Greg doesn’t need my problems to keep him up at night he can do that all for himself.

1 Like

you should consider that a Raspi doesn’t have a RTC. Operating with date/times esp. with higher ones may lead to unexpected values. This is one reason not to use an Raspi for anything related with encryption and crypto.

Raspberry pi = any linux (or arm mac) system in the time sence. Time and crypto etc can be use safely without issues.

The TS is just using the date(time) class for things it wasn’t made for.