being off by an entire minute would be an obvious problem
It does not have to be off by an entire minute to cause this type of problem. A few milliseconds would be enough if the code we see is only run once per minute to check if any emails should be sent. If I understand correctly, between greater timing accuracy and a more efficient scheduler, the code could be seeing "10.03" minutes in Windows and "9.97" minutes (then "10.96" when the email is sent "11 minutes later") in Linux.
| [reply] |
Rather than dumping everything, I modded the code to print out the quantities being compared. More testing required. I'll get back to you. Thanks,
Lars
| [reply] |
I was able to rule out time as the joker in the deck, if only because we're dealing with an interval of time, not the time of some event. Thus it shouldn't matter if time() returns different values on the two systems.
| [reply] |
The suggestion by haukex in 11114564 can be followed more thoroughly. Dump each variable and partial step involved in the calculation to track what happens. This means $min, $squelch, ($min - $squelch), and so forth. It is probably worth printing them at a higher precision than the default to see more, e.g. printf "%.17f\n", ($min - $squelch) (although both those should be integers based on the original post).
Although, "should be integer" depends what you have done with the numbers. Does your code use $min or $squelch in a floating point context? This could cause them to be used as floats in later calcs. I'm not overly familiar with the internals, though, so cannot say what to expect with any confidence.
| [reply]
[d/l]
[select] |
