Thanks but I’m aware of using the NotesDateTime class, the question is about using Lotuscript arithmetic.
Purpose of using native arithmetic rather than class is performance which is critical in what I’m working on (massively re-iterative function).
Using native NotesDateTime class is surprisingly inefficient (ie 10 seconds versus 1 second in native arithmetic in the sort of massive iteration I’m doing).
I don’t think the NotesDateTime class is that much slower. Have you profiled the code (for example using TeamStudio Profiler)?
I am sure you can write the code in a smart way so it still run fast.
Where are the dates coming from? Are you processing NotesDocuments? If so, you could speed up the process substantially thought soem clover code (use NotesViewEntry.ColumnValuses() to get the value instead fo doc.GetItemValue(), for example).
If you post a question about code, it always help if you describe a bit more what you are trying to do, that way people can help you better. If you don’t say that you have 10,000 date-pairs you need to compare, and what you tried, we can’t know that.
I suspect it has to do with the fact that dates internally are stored as Double.
When I declare aStart, etc as Double instead of Variant, I can see that the value for aStart and ahEnd are both 41412.4479166667, indicating to me that you have an infinite long series of 6:es, and it is rounding it.
My guess is that this is why, some kind of rounding issue deep inside the Lotusscript compiler.
I ran the code, as well as one using the NotesDateTime class, and the latter took (as you said) 10 seconds vs teh less than 1 second for the arithmetic version. This was on 100,000 comparisons each.
Assuming that you are reading the values from somewhere, I am sure that that reading will take much longer, and those 10 seconds should be negligable in the big picture, compared with teh benefit of getting the code done “the right way”, IMHO.
Yes I think you’re onto it. I posted this question on StackOverflow and received the following comment from Mr Richard Schwartz which correlates with your answer.
“Doubles are floating point numbers. They don’t have the precise values you think they do. So adding 30 minutes is just adding the nearest possible approximation. A native compare sees the inequality. The conversion rounds the values, making them equal.”
The ‘conversion’ he speaks of is the workaround I posted to this original topic.
The reason for the failure of the arithmetic is still a mystery but I have been able to work around it by converting the Doubles to a Strings then back to a Doubles inline as follows.