Our clocks went back an hour this weekend from BST to GMT. As a result a funny bug cropped up in my code. What I can't work out is if the source of the bug lies with Notes or not. It's not behaviour I've seen before.
Imagine a "subscription" document which has an ExpiryDate field, which should need no explanation, and also a GracePeriod field, which stores the number of days after the expiry date on which it actually expires.
To work out whether the actual expiry date had passed I use the formula:
@Adjust(ExpiryDate; 0; 0; GracePeriod; 0; 0; 0) < @Today
Yesterday (the 27th) I noticed that a document had expired a day early. Looking in to it I found that the change to the clocks had caused it.
For the document in question the formula being computed was:
@Adjust("25/10/2008 00:00:00"; 0; 0; 2; 0; 0; 0)
Now, I'd expect that to give me a date/time of "27/10/2008 00:00:00", but, in this case was giving me "26/10/2008 23:00:00". Hence it was indeed before @Today (the 27th) and so the formula returned true and the document expired a day early.
I can see what it's doing here. Two days is 48 hours and 48 hours after midnight this Saturday gone it was indeed only 11 PM on Monday, as the clocks went back an hour at some point in between. I just didn't expect @Adjust to be that clever. Has it always done that?
As a fix I found that ignoring the time component and only adjusting the date part stopped the extra hour being removed. The formula is now:
@Adjust(@Date(ExpiryDate); 0; 0; GracePeriod; 0; 0; 0) < @Today
For the example used above this gives me "27/10/2008", as expected. You live and learn. I'll try and remember to always extract the date part only from now on, assuming the formula isn't time-dependent, which it isn't in this case.
Am I missing something here? Did you all know of this and I've just been lucky never to have seen this behaviour before?