Clocks Go Back. Bug Comes Forward.
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?
Skip to the 
You can subscribe to an individual
IMHO, you just bypassed the problem. The better solution is to store the date without the time part, if you don't need it. That way, you'll never have problems with timezones or DST.
True. Trouble is I don't know where the time part came from. I'll investigate now and see if I can work it out...
It looks like Notes is adding it. When a new subscription document is created it gets the expiry date from a "setup" document like so:
Call doc.ReplaceItemValue("ExpiryDate", setup.ExpiryDate)
The ExpiryDate field on the setup doc is a date/time field that *only* stores the date. It seems that replacing the field on the subscription document with it adds the time part in too. I'm happy to turn it in to a date at the other end, as I don't fancy messing about trying to work out why Notes insists on adding it in the first place.
RTFM Jake!
@Adjust( dateToAdjust ; years ; months ; days ; hours ; minutes ; seconds ; [DST] )
Call notesDateTime.AdjustDay( n% [, preserveLocalTime ] )
@Adjust should have the [DST] keyword set to avoid problems when the clocks change.
The "manual" says:
"omit this parameter to not further adjust the time for daylight-saving time"
Even when I read it it still makes no sense ;o)
"Specify [INLOCALTIME] to further adjust the time for daylight-saving time if the adjustment crosses the boundary and daylight-saving time is in effect."
Seems pretty clear to me!
It's been in the "manual" since at least Release 4.6! ;o)
I'm not claiming it's a Notes bug. There's no need to get all uppity and defensive about it. My question was whether this is normal behaviour for @Adjust and you ever-so politely pointed out it was. Thank you.
The problem it turns out is that Notes is introducing the time part to a date time field where I don't want it to and where there wasn't one in the first place.
Either way, the fact I didn't realise there was a DST parameter to @Adjust after almost ten years as a Notes developer must mean there are others who didn't either. For that reason I find it's useful for me to blog things even when I know I'll be the one with egg in my face. It's a sacrifice I make for others. What I don't appreciate are "RTFM" comments!
Sorry Jake, I didn't realise you would be so touchy, no offence was meant, I was just having a bit of fun whilst answering your question.
I will endeavour to couch any further comments in a more friendly manner.
Your blog is one of the best out there, and one of the first I turn to when I have a problem.
No worries Travis. Apology (needed or not) accepted.
I wouldn't say I was overly touchy though. If ever I see RTFM then I read it as words rather than letters. If a comment starts with "Read the fucking manual Jake!" (which, effectively, is what it says) then I'm going to take umbrage.
And that's the trouble with writing and reading responses on any blog. It doesn't matter how you intend the reply to sound. Chances are, unless it's worded very carefully, it will come across differently. No matter what the intended tone, it's lost when it's rendered in black on white on the screen. That's what I've found over the years anyway. After years at it I should have thicker skin, but I'm a sensitive kind of person.
Glad you like the site by the way!
Hello Jake! I allways suffer from this disease here in Brazil when the DST period starts or ends. It does affect all date/time fields into documents in all databases by +1 hour at start and -1 hour at end. Due to this, our agents codes to lock or unlock documents to users starts to do their action in a 1 hour gap (early or later).
The same occurs with Sametime... Every meeting that was scheduled before the DST period will start 1 hour early...
Resuming: DST is every year a headache.
Must be nice to live in Arizona and not have to worry about all of this. :D
Hi Jake,
I got burned by this same thing a few years ago while designing an application that handled user ID revalidation. Users were spread out all over the globe and I *thought* I had accounted for everything in my code by supplying only dates & no times for the start/end dates. Then I found out that a date/time object or field that only has the date specified automatically uses midnight as the time.
After that, I used the PreserveLocalTime flags but still found problems (probably with my code) because we had users distributed across so many time zones, with DST sometimes in effect, sometimes not.
Finally, I started storing the time zone of the user, adjusting the dates/times to that zone and that seemed to correct the problems. At least it did in testing. I left that company before this year's user revalidation took place! ;-)
Anyway, not much insight really--just a sympathy comment.
P.S. And I'm pretty sure I made the above-described app far more complicated than it needed to be. What can I say? Time Zones and DST overwhelm me.
@mdmadph: I used to say, "Damn you, Arizona, and your lack of agriculture!"
Throughout my 30 year career dates and times have burned me more than any other single issue. And I'm not just talking Notes either.
On one job I had to rewrite the standard time-date function library used in two cross compilers so that the base epoch was 1980 instead of 1970. (We were writing firmware for embedded controllers that run the fare collection systems on subways and buses in NYC and Washington D.C., among others.)
In that project and all projects after that where I could control how date/time was stored, I've always kept it in UTC/GMT. This lets me compare date/time no matter where it was generated in the world. Then, if a local user needs to see the date/time in his/her local, I just adjust it using the local time zone.
I wish all computer clocks were set to UTC/GMT rather than local time. The way it is now if you want to know which of two files is newer from two different computers you have to know the local time zone for both of those computers and make the correction.
Peace,
Rob:-]
If setup.ExpiryDate indeed contains no time part (I think you checked) and it is added by ReplaceItemValue, one way to get rid of it is by using doc.CopyItem.
Been using Notes since 2.0 and still hate dealing with dates & time. I spent this afternoon puzzling/looking at a problem with notesdatetime.timedifference, and it's VERY similar to your @Adjust. One date was during BST (yes I know it's GDT or something now), and one during GMT (or is that UTC?). Sure enough, dividing the seconds down into days, I gained a day (00:00 moving to 23:00 previous day). No preserveLocalTime parameter with that method though....
I must read Codestore more regularly
I must read Codestore more regularly
I must ......
Oh yeah, Notes has funny way of handling Date/Time. There seems to be several Date/Time types inside Notes. Even in LotusScript there seems to be a DateTime Variant DataType 7 which is used in the functions like DateValue() or CDat(), and also a Variant of type DATE which is returned by NotesDateTime.LSLocalTime. I dunno if they are the same, but both these Variants must have a Time component. It seems via LotusScript, there's no way to drop the time component. However @Formula seems to be able to create Date\Time values without a time component.
If you create a Computed Field with just @Today, the Time component does not exist in the field, but a Field that is populated by the LS function Today() has the 00:00:00 time component added. WTF.
@Kipil: So true. Once, I used evaluated @Formulas because it's the only way to append dates to a date list without also adding time components.