Fw: Daylight Savings Time adoption by the State of Indiana on April 2nd 2006 may affect calendaring

Notes Domino Information <ndinfo@xxxxxxxxxx> 
03/22/2006 01:29 AM

To
rob@xxxxxxxxx
cc

Subject
Daylight Savings Time adoption by the State of Indiana on April 2nd 2006 
may affect calendaring






This note contains links (URLs) to technical support documents (technotes) 
related to the adoption of Daylight Savings Time (DST) by the State of 
Indiana in the USA. You are receiving this notification because you are a 
customer who has called us for technical support in the past year. If you 
do not wish to receive notifications like this one on other topics in the 
future, please reply to this email and change the Subject field to: 
unsubscribe <e-mail address>, e.g. unsubscribe user@xxxxxxxxxxxxxxx

This is a special mailing separate from regular Frequently Asked Questions 
(FAQ) mailings to address problems specifically related to calendaring in 
our software products, which may occur due to the change of time zone for 
the State of Indiana on April 2nd 2006. Features/functions in Workplace 
Portal and Collaboration products, such as IBM Lotus Notes/Domino, IBM 
WebSphere Portal, IBM Workplace Collaboration Services, IBM Workplace 
Collaborative Learning, and IBM Lotus Learning Management System may be 
affected by this change.


IBM Collaborative software products
The technote below explains how to react to the change. Please review it 
carefully if your time zone is "Indiana (East)", or if you have schedule 
dependencies that involve Indiana based people or systems.

Title: State of Indiana time zone changes beginning April 2, 2006 affect 
Lotus software
Link: http://www.ibm.com/support/docview.wss?rs=0&uid=swg21232886

Most of our customers run on the Windows platform and let our products 
rely on the Operating System (OS) time. The DST setting will in most cases 
be changed by changing the OS time zone setting from "Indiana (East)" to 
"Eastern Time (US & Canada)", although in a few cases a manual switch to 
DST may be needed, see the technote above (e.g. iSeries). The typical 
issue encountered is that calendar appointments during DST, April 2nd - 
October 29th 2006, which were saved prior to changing the OS time zone, 
and therefore assumed to occur in Standard Time, will be one hour off when 
viewed in Daylight Savings Time. This is not a malfunction of the 
software, but rather a consequence of the meeting having been set up when 
DST settings were different. However, it is not necessarily appropriate to 
change all meetings back by an hour. Please see the detailed discussion in 
the technote. The above technote also provides links to information about 
how to change DST on AIX and iSeries/OS400 platforms.


Changing calendar documents
An important consequence of the permanent time zone change is that all 
existing calendar documents, saved prior to changing the OS time zone 
setting, and reflecting times of meetings or events occurring in future 
summer (DST) months will appear an hour later when viewed in Savings Time. 
An automatic correction of this issue, by moving all meetings occurring 
during the DST period and scheduled in Standard Time back by one hour, is 
in many cases not appropriate! Please consider these two examples in 
detail:
1.      Say someone in Indianapolis in mid March set up a meeting with a 
team in California to be held at 12 noon Indianapolis time on Monday April 
3rd. If the system in mid March was still based on the Indiana (East) time 
zone, then it counted on there being no DST in Indianapolis on April 3rd, 
but DST was anticipated to apply for California on April 3rd, so the 
system expected them to be two hours apart on April 3rd. The meeting is 
therefore at 10 am Pacific Daylight Time (PDT) on April 3rd. When the 
Indianapolis office changes the time zone setting in the OS to Eastern 
Time, DST will kick in on April 2nd, and the meeting on April 3rd will now 
show as 1 pm Eastern Daylight Time in the reconfigured calendar, which is 
still equal to 12 noon in the old Indiana time zone (which doesn't apply 
any more). However, if the Indianapolis team moves the meeting back to 12 
noon Eastern Daylight Time in Indianapolis, it will be 9 am PDT in 
California, not 10 am PDT. So by moving it back to the intended time in 
Indianapolis, they will be rescheduling for participants in other states. 
2.      Consider a dental practice or a school district. All customers are 
local. All appointments are in local time. When central Indiana changes 
from Indiana (East) Time to Eastern Time, the dental practice or school 
district will want to move every single appointment back by an hour. A 
customer who scheduled a dental check-up, or a school bus for a sports 
game, at noon when the Indiana (East) Time Zone applied, still expects 
that appointment to be valid for 12 noon in the Eastern Daylight Time zone 
that now applies.

The contrast in the two examples demonstrates that whether or not you want 
to move all meetings back an hour depends on who you're meeting with. If 
you have appointments with out-of-staters, you need to think about whether 
or not to reschedule. The fact is that the time difference between Indiana 
and other states is changing, and that will inevitably cause needs for 
rescheduling. Resolving which meetings to reschedule, or not reschedule, 
requires intelligence about the location of all participants, their free 
time availability, and business preferences. That is why there is no 
single "fix" to resolve calendar issues as a consequence of the time zone 
change. There is no malfunction in our software relative to this change. 
Since this is a permanent change of time zone, you will only need to deal 
with these rescheduling tasks once.

Our general recommendation is that companies ask individual meeting 
owners, who are going to change their OS time zone (i.e. mostly Indiana 
based employees), to do the following: 
- print their calendar for the DST period April 2nd - October 29th of 2006
- apply the OS time zone change and restart their system,
- review their calendar for the DST period April 2nd - October 29th and 
resolve which meetings to reschedule, and which not to reschedule.
For companies with multi-state and international operations or 
interactions, this approach will likely minimize confusion and wasted time 
due to misunderstood meeting times.

Users whose OS time zone setting isn't "Indiana (East)", and who hasn't 
recently used that time zone setting, are not immediately impacted. 
However, anyone outside Indiana scheduling meetings or other events with 
participants in Indiana are wise to double check appointments to avoid 
wasted time due to misunderstandings.

Kind Regards,

The IBM Workplace Portal and Collaboration Software team