# Math not Mathing

I am working with dates and seconds and coming up with a “Instant Date” based on a formula provided to me. I have reversed that formula and written it out in my desktop app to convert dates to their “Instant Date”.

I have tested this in a standalone app and it works great. The problem is when I move this in to the actual app that it needs to work in, the final value is changing.

Here is the code I am using (I’m iterating through a sql database and putting the values in to a listbox):

``````dim dateline as String = row.column("Date").StringValue //THE TEST DATE IS 07/25/18

dim year as string = "20" + dateline.Right(2)           //CONFIRMED OUTPUT: 2018
dim month as integer = dateline.Left(2).ToInteger       //CONFIRMED OUTPUT: 07
dim day as Integer = dateline.Middle(3,2).ToInteger     //CONFIRMED OUTPUT: 25
dim dcheck as new DateTime(year.ToInteger,month,day)    //CONFIRMED DATE IS ACCURATE
dim past as new DateTime(1900,1,1)

//THIS OUTPUTS A VALUE OF 43306 (WHICH IS WHAT IT SHOULD BE)
dim calc as Integer = ((dcheck.SecondsFrom1970 - past.SecondsFrom1970)/86400)+2

//THIS SHOULD OUTPUT 5603385600 BUT IT OUTPUTS 1308418304
// (43306+21548)*86400 = 5603385600
dim calc2 as Integer = (calc+21548)*86400

//OUTPUT values to Listbox for troubleshooting
``````

What would cause calc2 to output a completely different number?

5603385600 is outside what 32bit can handle (according to the docs it goes to 2,147,483,647), so it makes sense that your number produce 1308418304.

Test code:

``````Dim calc2 As Int32 = 5603385600 //calc2 will be 1308418304
``````
2 Likes

Its not. Its 64.

That’s weird as Int32 produces the exact results you posted.

Tested with mac, don’t have Windows around. (See my updated post)

You nailed it, not sure how but but architecture was changed to x32.

One question, this code:

``````//THIS OUTPUTS A VALUE OF 43306 (WHICH IS WHAT IT SHOULD BE)
Dim calc As Integer = ((dcheck.SecondsFrom1970 - past.SecondsFrom1970)/86400)+2
``````

produces 43305 on my mac.

(dcheck.SecondsFrom1970 - past.SecondsFrom1970)/86400) + 2 = 43303.958333 + 2 = 43305.958333 so Integer of that is 43305.

If that produces 43306 with windows but 43305 with mac, that could be a problem.

Yeah it’s odd. On a Mac its off by 1. I actually have that +2 at the end as a text box so it can be updated. Im not sure what causes it as of right now, but once I figure it out I will put in a more long term solution.

I think it might have to do with timezones but I haven’t been able to consistently prove that yet.

Express explicitly the proper container type, in this case Int64

It may be possible that Xojo have a code base with possible multiple points of failure, like a math lib for Windows, another one for Mac, another for Linux, etc so when they touch one place and forget the equivalent in another platform, inconsistencies are introduced.

Yes, that’s why I want someone with windows to test the code to create an Issue with a sample.
Thanks.

Paste the desired test code here and I’ll run it for you guys and show the results.

Try this:

``````dim dateline as String = "07/25/18" //THE TEST DATE IS 07/25/18

dim year as string = "20" + dateline.Right(2)           //CONFIRMED OUTPUT: 2018
dim month as integer = dateline.Left(2).ToInteger       //CONFIRMED OUTPUT: 07
dim day as Integer = dateline.Middle(3,2).ToInteger     //CONFIRMED OUTPUT: 25
dim dcheck as new DateTime(year.ToInteger,month,day)    //CONFIRMED DATE IS ACCURATE
dim past as new DateTime(1900,1,1)

//THIS OUTPUTS A VALUE OF 43306 (WHICH IS WHAT IT SHOULD BE)
dim calc as Integer = ((dcheck.SecondsFrom1970 - past.SecondsFrom1970)/86400)+2
//calc = 43305 or 43306?

//THIS SHOULD OUTPUT 5603385600 BUT IT OUTPUTS 1308418304
// (43306+21548)*86400 = 5603385600
dim calc2 as Integer = (calc+21548)*86400
``````

I get calc = 43305 with mac.

Xojo 2023 r1.1 Windows x64

I have ran it on 4 different machines and 3/4 give me 43305 and the 4th which is on a Frame VM gives me 43306. Because of this in my GUI I have a text field that allows me to change that +2 to whatever number I need to get the expected outcome. This is why I think, somehow, this is related to timezones and that VM is forcing it to not UTC. But I am unsure exactly.

Try to get the infos of all involved machines:

Locale, TZ, OS and version, CPU.

With this we probable have all that is needed to observe some correlation-maybe-causation,