Help needed on web service response

[charvista]

Does this work on your x86 systems

You probably mean my x64...
Well, in the weekend I am not at the same place as during the week, so now I have my x86, and the last now_pb reflects the Date() again.
You will now need to wait for Monday evening to know if it works on my x64 either...

It is possible that the formule worked fine on your x86 computer, but you cannot expect the same on a x64, or vice-versa, when a value has more than 15 digits. It is certainly not a coincidence that the Business Basic programming language I used before could handle a maximum of 15 significant digits, and the maximum internal function PRECISION was 14. PRECISION was meant to have a maximum of 14 digits after the decimal point were allowed, or at least rounded to these 14 digits. You see it: 14 decimal digits and minimum 1 digit in front of the decimal point = 15. If there were 5 digits in front of the decimal point, then the decimals were rounded to max 10 digits = 15. Fifteen is the safe limit, plus one byte for the sign = 16 = ( 2 x 8 ) bytes.

[Little John]

@Project Mayu:
It's fine that it works for you using a .d variable for the ticks. However, it is strange that .q does not seem to work on x64 systems.

Does this work on your x86 systems

You probably mean my x64...

Ooops. Yes, your and Project Mayu's x64 systems.

You will now need to wait for Monday evening to know if it works on my x64 either...

Thanks in advance that you are going to test it again.

It is possible that the formule worked fine on your x86 computer, but you cannot expect the same on a x64, or vice-versa, when a value has more than 15 digits. It is certainly not a coincidence that the Business Basic programming language I used before could handle a maximum of 15 significant digits, and the maximum internal function PRECISION was 14. PRECISION was meant to have a maximum of 14 digits after the decimal point were allowed, or at least rounded to these 14 digits. You see it: 14 decimal digits and minimum 1 digit in front of the decimal point = 15. If there were 5 digits in front of the decimal point, then the decimals were rounded to max 10 digits = 15. Fifteen is the safe limit, plus one byte for the sign = 16 = ( 2 x 8 ) bytes.

All values used here are whole numbers in the range of a quad variable, and we are not talking about sophisticated memory operations, but just about basic arithmetic operations and Int(). That should definitely give the same result on x86 and x64 systems. I have also used different BASIC flavours in the past, and never encountered something like that before. This whole thing looks to me like a bug in the x64 PB compiler.

Regards, Little John

[charvista]

@Little John
Sorry to be 1 day too late due to a car problem.

To answer your question about #SECONDS_UNTIL_1970_01_01 = 62135596800:
Yes, it works fine both on x86 and x64.

Cheers.

[Little John]

Hi charvista,

that's good news.
Thank you very much for checking it, especially on x64.

Best regads, Little John