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.
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.
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
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.
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.
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.
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.
