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:
- WebAccess
- 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 5)You need to be a registered member to rate this post.
Loading...
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.
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.
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.
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.
[…] 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. […]