IBM's DST Patch code

HCL Domino Domino Forum
1

IBM has provided the following code to adjust date/time fields that fall into the new DST time period:

Dim doc As NotesDocument

Dim vArray () As Variant

Dim startDateTime1 As New NotesDateTime (“3/11/2007 2:00:00 AM”)

Dim endDateTime1 As New NotesDateTime(“4/1/2007 2:00:00 AM”)

Dim startDateTime2 As New NotesDateTime (“10/28/2007 2:00:00 AM”)

Dim endDateTime2 As New NotesDateTime(“11/4/2007 2:00:00 AM”)

…

Forall i In doc.items 'Check all items in document

If i.type=1024 Then 'Only act on items of Type DateTimes (1024)

Redim vArray (Ubound(i.Values))

For j = 0 To Ubound (i.Values) 'Loop in case of multiple values

Set datetime = New NotesDateTime (Cstr(i.Values(j)))

If datetime.timezone<>0 Then 'Do not act on Time only fields

If ((datetime.LSLocalTime >= startDateTime1.LSLocalTime) And _

(datetime.LSLocalTime < endDateTime1.LSLocalTime)) Or _

((datetime.LSLocalTime >= startDateTime2.LSLocalTime) And _

(datetime.LSLocalTime < endDateTime2.LSLocalTime)) Then

datetime.AdjustHour (-1)

End If

vArray(j) = datetime.LSLocalTime 'Reset array value

End If

Next

i.Values = vArray 'Store array into the item

End If

End Forall

Call doc.Save(True, True)

The problem is, it does nothing to determine if the time zone is ALREADY correct. It is possible that there will be some documents that were saved from a PC with the OS patch (and therefore don’t NEED to be updated), and other saved from a non-patched machine that really need to be fixed. Unless I’m missing something, this will result in any documents saved post-patch to be an hour off for that time frame.

Does anyone know of a solution to change only the documents that need updated?

2

Subject: IBM’s DST Patch code

The short answer is “No”. Now let’s explore that.

When a document object is modified, for whatever reason, the modification timestamp for the object is likewise updated.

OK, great you’re thinking – if a document has been updated since (just for giggles) Jan 1, it must have the right date information.

Wrong.

Just because a document has been updated, does not mean the time has been updated. Maybe the subject was updated or the location moved. There is no explicit marker for a change in the time stamp. Furthermore, let’s say the time was updated. Was it updated because of the DST change, or because of a change in the appointment time?

Ultimately, there is no fool proof automated solution (we had a saying at the old Data General Corp – make a system foolproof and only a fool will want to use it), so what can you do?

1 – Make an opt-in/opt-out system. Provide your user community the ability to participate in/withdraw from a mass migration. Also add an agent that lets the user select an appointment and undoes the change (i.e. the user selects an appointment, and the agent puts the old time back)

2 – Provide the user with an agent that manually updates one or more selected appointments. The downside to the user is that it will lock out their workstation for a time, and I’ve no idea how it will deal with instances of a calendar object that are in other user’s mail files. Here too, adding the undo agent is a good idea.

Regards,

David

3

Subject: RE: IBM’s DST Patch code

I haven’t completed testing, but I don’t think you are correct about one thing: even if you do not explicitly change the time field, I DO think the DST settings get corrected when the form is re-computed at save time. I’m pretty sure that opening a document, hitting F9, and saving will correct the DST issues on a document. Identifying them in an agent is a different matter, unfortunately.

4

Subject: RE: IBM’s DST Patch code

If that is the case what if you had an agent that cycled through all of the documents in a DB and did a ComputWithForm and then saved it? That should accomplish the same thing as opening the doc and F9 and save (almost anyway, ComputWithForm is not fool proof).

5

Subject: IBM’s DST Patch code

Hi,

Which version of the agents are you using?

JYR

6

Subject: RE: IBM’s DST Patch code

The only thing I’ve seen from IBM regarding fixes to documents not in databases supplied by IBM is what I pasted into my original post. If there’s a another version out there, I’ve not seen it.

7

Subject: RE: IBM’s DST Patch code

Hi Steven,

Are you talking about this technote?

Daylight Saving Time (DST) 2007 effects on Date/Time fields in Lotus Notes and Domino

What follows is a LotusScript example, which demonstrates a basic approach to performing the necessary checks and updates to a selected set of documents. This example is not dependent on knowing the Date/Time field’s name within a document as it uses a Forall loop to cycle through all items in a document using the Items property (of the NotesDocument class.) The example is not intended to be a fully-developed solution, but as a means to demonstrate an approach to such a solution. It is up to administrators or application developers to build on this example to create a solution that applies to the target application and/or environment. IBM Support is not available to further customize the example for particular applications or environments.

Warning! This example is not suitable for updating Calendar and Scheduling (C&S) entries in a Notes mail file or Domino Web Access (DWA) mail file, or entries within a Notes Resource Reservation (R&R) database. For details on issues involving C&S and R&R entries,

If it’s for your mail dbs, you should look here

Agents for updating Calendaring and Scheduling entries and Resource Reservation entries for Daylight Saving Time (DST) 2007

Maybe you could take codes from thoses agents and fit it to your need because those agents takes care of the time zone.

JYR

8

Subject: RE: IBM’s DST Patch code

Yes, that is the technote I’m referring to. Howver, the code provided there does nothing to differentiate between a date on a workstation using the new DST settings and the old.

In other words, lets say my PC was patched for the new DST settings and yours was not, and we both go out a create an entry in a databasae with the date of 3/15 at 10AM. As things stand now, your entry would be an hour off. If we ran the code in the technote (what I pasted into the first post of the thread), BOTH of our entries would be adjusted back an hour, so now yours is correct and mine wrong. I’m wondering if there is a way to check to see if an entry already has the correct DST settings before rolling it back an hour.

9

Subject: RE: IBM’s DST Patch code

Hi Steven,

Like I said, you should look at those agents :Agents for updating Calendaring and Scheduling entries and Resource Reservation entries for Daylight Saving Time (DST) 2007

There is a few functions that you could reuse ti fit your need, those functions checks the TimeZOne value.

new timezone table

TZTable(0) = "Z=9$DO=1$DL=3 2 1 11 1 1$ZX=1$ZN=Alaskan"

TZTable(1) = "Z=8$DO=1$DL=3 2 1 11 1 1$ZX=51$ZN=Pacific"

TZTable(2) = "Z=7$DO=1$DL=3 2 1 11 1 1$ZX=42$ZN=Mountain"	

TZTable(3) = "Z=6$DO=1$DL=3 2 1 11 1 1$ZX=18$ZN=Central"

TZTable(4) = "Z=5$DO=1$DL=3 2 1 11 1 1$ZX=25$ZN=Eastern"

TZTable(5) = "Z=4$DO=1$DL=3 2 1 11 1 1$ZX=5$ZN=Atlantic"

TZTable(6) = "Z=3003$DO=1$DL=3 2 1 11 1 1$ZX=48$ZN=Newfoundland"

oldDSTrule="DL=4 1 1 10 -1 1"
10

Subject: RE: IBM’s DST Patch code

Maybe I’m missing something, but aren’t those agents checking that data against fields on a calendar entry? If I’ve got a document with a simple date/time field on it, do I have enough information to use that stradegy?

11

Subject: RE: IBM’s DST Patch code

have you read through this technote to see if your question is answered?

http://www-1.ibm.com/support/docview.wss?rs=899&uid=swg21254639