If you look at a document created in the ‘new’ time period for any year (ex: between Mar 11 and Apr 1) on a patched and an unpatched system, the times differ by an hour.
Everything I can find except tech support calls to MS, point to this being a problem with the way the patch is implemented on Windows. MS points to the way 3rd party apps use the patch.
I have listened to the indicated podcast at idonotes and it talks exclusively about mail/cs except for one brief mention at minute 7 that says Notes/Dom gets the DST from the OS.
Is there anybody who can point to a definitive resource that describes what happens and why?
Anybody have a fix or workaround? We’re writing up a document that describes the problem so if/when we’re audited and somebody gigs us on dates in records that don’t match dates in audit trails, we can at least say we know what happened and chose not to do anything.
Excellent description of the problem. MS changed the rules on dates and times, everybody else now needs to play catch up and hope that the d/t rule implementation doesn’t change again.
Subject: RE: DST, dates prior to 2006 - an explaination
In case this helps anyone else, I’ve written some formula code for a column in the Calendar view so that entries that are an hour off show up in a highlighted color. It looks for entries between March 11th and April 1st only. At least from the view level it will remind people that some of their meetings are actually an hour earlier.
Right now it only handles Eastern, Central, and Mountain time zones, but I’ve explained how to add other zones if necessary.
Well in calendar entries the time zone is handled correctly in the documents but displayed incorrectly in the calendar view. If you go back to a calendar entry in 2006 that falls between the the affected date range you can see that the calendar shows off (ahead) by 1 hour but if you open the document the time appears correctly. So I guess 1 could say that the time zone is handled based on the way the application (form) was setup to handle the time zone calculation. there are 2 fields on the doc (EndTimeZone / StartTimeZone) that store the DST rules. I suppose if these “rules” were applied to other time sensitive documents the times would calculate properly. Does this sound like a safe assumption? Am I understanding this correctly?
right, so one might say that your apps/forms were not programmed to handle DST correctly. So the question remains, is it a MS problem, an IBM/Notes problem or a dev/design problem? That’s the point I was trying to make. Maybe your Notes forms need to have those fields added to handle the DST change correctly? Now I know this will be met with alot of controversy but IBM can easily pawn it off and just say that they’ve designed for it and you should too.
By default, Notes forms do not handle DST changes that use OS level custom modifications (ie, the 2007 patch that adds entries to the registry of Windows OS).
If this is correct, that would mean that any developer working in a country where these patches get applied a lot (Australia is one I think) would, by default, always have date/time values off by x hours for the non-standard DST periods.
This is not the case where a country only uses the ‘standard’ DST offsets.
This has existed in Notes since day 1.
Crap…
Do you know if adding these fields makes Notes work when there are multiple DST offsets in the registry?
Does adding the fields make the date handling retroactive to all docs created using the form?
I feel like I just got hit in the side of the head. I have NEVER heard of those fields - no class, no article, never… (or if I did, it just passed in one ear and out the other).
I’d say we are now thinking along the same lines. You ask some valid questions, though, and of course I don’t have the answers because it would take a fair amount of testing. Probably worth a call to IBM support.
I know the DST team is monitoring the forum and has asked for us to log issues against the DST category.
Can you chime in here? What’s up with non-C/S date/time fields? Were we supposed to create DST offset fields in all of our docs since day 1 or is there something else going on here?
Can you recommend a fix or workaround?
If we are NOT supposed to be adding these fields into our designs, why are all ‘new DST’ dates being screwed up in prior years?
The reason I believe it is appearing correctly is because the date and time fields are separate fields. From what I read the DST Law changes do not effect date only or time only fields. My thought was that the StartTimeZone and EndTimeZone are used when populating other participates calendars. The code needs to know what timezone the meeting is coming from so when it populates someone elses calendar it puts in the correct time.
We’re back to the C/S thing (unless I’m not understanding your post). The problem I’m seeing is with non-CS d/t fields.
My ini does NOT have DSTLAW settings but my computer has bee patched at the OS level (I can see the registry settings for the new DST rules).
Do StartTimeZone and EndTimeZone have meaning and utility in a non-CS environment? Are we SUPPOSED to be creating these fields for ALL of our apps that capture D/T information?
From what I believe the StartTimeZone and EndTimeZone fields are only in the CS applications. They are probably used to make sure entries in all participant calendars are correct.
In a non CS application these fields are not needed. At least I have never read anything that points to their need.
My issue is the same as yours, non CS applications date/time fields have incorrect times for years prior to 2006 that fall within the new extended DST time frames after the OS patch has been applied.
Concerning a previous post that time dates were correct in the CS app because they included in these fields I believe is incorrect. The fields are correct because the date and time were split into separate fields. DST only effects fields that include both date and time. The view is incorrect because it uses a field which merges the date and time into one field.
For anyone who does not think this is a problem, please take the time to create a test database, with one form, which has one editable date time field. Find a PC that has not been patched and create a record with the time 11/1/2006 11:00 AM. Then find a PC that has been patched. The date/time will be 11/1/2006 12:00 PM. If date/times are a critical part of your applications this is a big deal.
To detemine if the patch was applied run regedit and look into HKey_Loca_Machine / Software/ Microsoft/ WindowsNT/Current Version/Time Zones/Eastern Standard Time. If there are no folders within the Eastern Standard time the patch was not applied. If you see Dynamic DST 2006 and 2007 then the patch was applied.
Hopefully one day Lotus will use these Dynamic DST entries to display all date/time fields correctly.