Cool Solutions

DST in Australia



By:

January 17, 2008 9:02 pm

Reads:2,800

Comments:3

Score:Unrated

Here we go again. This year some of the Australia territories decided to change the end of their DST periods by one week.  We are currently planning on how we tackle this.  We have 2 basic choices and some variations on the theme – do the same as we did for the US or the same as we did for New Zealand.  To summarize the options that we are looking at:

Option 1

For the recent New Zealand DST changes we worked with OMNI to get a blanket license for their Riva product and a custom build DST module.  This module attached to each mailbox and inserted a search folder with a fixed set of criteria.  Basically it searched for all SENT appointments in the mailbox that fell inside of those extra weeks of DST.  The user could then go to this folder and selectively resend those appointments that needed resending.

There are a couple of modifications that we can make to the query:

Option 2

Same as #1 except it will show both SENT and RECEIVED appointments and users are given instructions to only move the ones they SENT and notify the other senders to resend theirs

Option 3

Same as #1 except if you know that all workstations were patched on the same day that you can give this date as an extra parameter and the search folder will only display appointments SENT or RECEIVED before that date.  This has an additional benefit – as other senders resend their appointments they ‘disappear’ from the search results.

The downsides of all 3 of these options are the same.

1.  Users need to check ALL the appointments to see if they are accurate

2.  As a sender resends their appointments the search folder will either double up on the sent items, or will not show the newly sent item (for #3)

If we chose one of these options then we will likely do it in GWCheck instead of licensing Omni’s RIVA again.  We have enough lead time and a release vehicle in SP3.

Option 4

We do another version of GWCheck, like we did for the US change.  This GWCheck can look at the Timezone definition on any appointment, sent or received.  If the Timezone definition is incorrect then the GWCheck will intelligently move the appointment to the correct time and place a hidden flag on the item.  If the timezone information is missing or correct then the appointment is not moved.  The details escape me on this last point, but those that were not moved had a different hidden flag applied – the part I can’t remember was if it was just those that had missing timezone information, or all.

It then created 2 search folders that searched on the hidden flags – one you show users what was moved, and one to show them what was not, so that they could selectively resend them.

The Timezone information is placed on any appointment created with the latest Windows client (6.5.6 and newer I seem to remember), the latest Linux/Mac clients (7.0.2?), WebAccess (possibly also 7.0.2, but it may be 7.0.3) and SOAP clients (7.0.3?).  The prior exceptions, though we should be doing it globally now, was on posted appointments.  So, if your users are using the latest windows client then we can probably intelligently move 80-90% of appointments, if they are working like the rest of us do – so they only need to review 10-20% of their total.

So after having explained all of that I have spoken to a number of customers in Australia and the overwhelming feedback was  to go with one of the first 3 options and not attempt to move any appointments.  The reasons given were that it was less confusing for the users to not have appointments moved for them so that they could be sure that they had checked them all themselves.  It was also felt that most users won’t yet have appointments in the problem period and Microsoft released the workstation updates in a patch in December – we are defendant on this patch for the DST calculations.  As this was done quite early if that patch was applied there will be very few problematic appointments.

So my question to the rest of you is if this seems like some reasonable assumptions and if this is the way to go?

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading ... Loading ...

Categories: Uncategorized

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

3 Comments

  1. By:Dave Dabinett

    Hi Alex,

    This is of great importance to me as a partner supporting many GroupWise clients in Sydney.

    I am happy with a solution that will require minimal input from end users.

    Will the GWCheck with the TZ2007 option work for us, or will there have to be a new update created with the settings for our timezone?

    Cheers,
    Dave

  2. By:John

    Hi,

    Appreciate if any one can guide us through the steps to modify the DST on a GroupWise Server PO in Australia, (some GroupWise server PO are staged in DST and non DST sites.

    Any tool/utility/patch (TZchange2007) to modify the DST on GroupWise Server (Australia) would be highly appreciated

    Cheers
    John

  3. By:Tim King

    Alex,

    Could you please advice whether you are planning to provide a patch for GW 6.5 WebAccess as was done for last years US time zone changes?

Comment

RSS