Novell Cool Solutions

Timezone changes & GroupWise



By:

March 15, 2006 2:42 pm

Reads:4,658

Comments:5

Score:Unrated

Print/PDF

I have been getting a lot of questions recently about all of the impending timezone changes and what Novell is doing. In fact, whilst writing this I had someone at my door with that very question. In my opinion these issues are probably more widely impacting than anything that Y2K brought us, and I wish that governments would just leave it alone. I know that there are places in the world where timezones are a constantly moving target, Israel I think changes their Daylight Savings start and end almost yearly and I have it on good authority from a Muslim colleague that many Muslim countries change their DST start and end to shorten the days during Ramadan. The difference between these places, and what is happening in Australia, Indiana and the US as a whole, is that it’s been happening for years and the locals know how to deal with it. The problem is that when the US has their mass change next year (has the bill even been passed yet?) the whole world needs to adjust to the change.

Time issues are always tricky and are guaranteed to bring a groan from any support engineer. If you came to our office in March or October you’d see us all walking around looking at our watches, moving imaginary hands with our fingers wearing puzzled expressions and trying to figure out questions like ‘if it was 2pm on March 29 and DST didn’t shift in Canada, then what colour shirt would President Mbeki be wearing?’ Well not quite, but that’s how it feels sometimes.

So, what is GroupWise development doing about this? The answer is nothing. Surprising answer maybe? Well, I’ll expand on it and I also plan to write a TID. For the most part GroupWise takes it’s time from the workstation, so as long as the workstation time and timezones are correct you should be ok. The other place we take time from is the server OS, so the same applies there. There are two exceptions:

  1. WebAccess
  2. ConsoleOne Timezone administration

WebAccess follows the time assigned to the PostOffice and GW has a number of Timezone defintions that are changable in ConsoleOne (Tools | GroupWise System Operations | Timezones). Anyway, that’s enough for now, but I’ll be revisiting this again soon.

BTW, white with blue stripes is the answer. :)

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

5

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.

5 Comments

  1. By:Steve Druck

    Hi Alex,

    You are right that Israel changes the Daylight Savings
    start and end every year. It depends on what political
    coalition forms the government and (literally!) on
    the phases of the moon. The latter is because the
    Jewish calendar which determines our holidays is lunar.

    But, while we know how to deal with the problems, we
    don’t like to have to do so. Every year, when we learn
    what the settings are, we have to push them out
    to all our users’ PCs. We hope that we are not too
    late in doing so because some of our users have
    scheduled appointments too far in advance. We always
    get angry calls to our help desk twice a
    year for workstations that we miss or from users
    who have already scheduled appointment.

    It would be much better for us if GroupWise would
    allow us to configure the Daylight Savings time
    settings at the post office. I know the advantage
    of taking the settings from the workstation –
    workstations in different time zones see the
    appointments in local time – but it would be much
    easier for us for the Post Office to keep the
    information about all the time zones and for
    the clients only to chose the time zones their
    workstations are currently in. This would be
    great for mobile users.

  2. By:Alex Evans

    Hi Steve – good to see you on here, it’s been a while since we spoke. I know where you are coming from on this, but from Novell’s point of view, since we started taking the time from the workstation the number of DST calls that we got reduced dramatically.

    One of the major issues that we face is that there is only one definition for any particular timezone – what I mean by this is that there is no mechanism to modify a timezone and say that in 2006 DST starts here, and in 2007 it starts there. So when modiying timezones for 2007 we need to wait until the 2006 DST has begun, otherwise you break time in 2006.

    What is also true is that this problem is not limited to Novell, everyone has to deal with it.

  3. By:Steve Druck

    In ConsoleOne, under Tools>GroupWise Systems Operations>
    Time Zones, I can edit the start and end of Daylight
    Savings time of each named time zone. If all that I
    had to do once a year was to edit the Israel entry,
    that would be great.

    I will admit that Israel’s situation is unusual, but,
    as you indicate in your entry, it is not unique. It
    is we the customers who are getting the DST calls.

  4. By:Alex Evans

    The main reason that we moved away from using the PO timezone is because anyone travelling outside their PO’s timezone had the wrong time on their appointments – the only way for this to work is to use the workstation timezone.
    Israel aside, this was a pretty successful change – until now. But I also really want to make it clear that GroupWise is not the problem here – all calendar systems have the same issue, as do all your VCR’s, alarm clocks, DVR’s – whatever has hardcoded timezones.
    MS are releasing (already released?) Windows patches to address this, which means that there should be nothing at GW users have to do going forwards.

    After this reply I am going to add someone elses comment, which came in through another channel – and I’ll address that too. One thing is definately true, time problems are a contentious issue.

  5. […] It’s been a few weeks since I posted anything and this time I have no excuse.  This post is going to be a little random as I have lots to update you with.  Firstly – DST.  Aaaargh!  I have no idea what happened, noone seemed to care much about it in 2006 then, come New Year, everyone wants to know whats going on.  I posted on it a few times last year and Ken brought it up again this week. […]

Comment

RSS