Summer clock in Israel for 2006

On the 30th of March 2006 Israel will be switching to Daylight Savings Time (aka “Summer clock”). For those of you who don’t know, because of various political reasons, the Israeli government keeps shifting the DST entry and exit points each year, which causes a great pain in the back-end for us IT people.

That’s right ! Israel is rather special when it comes to summer clock – the actual dates of summer clock’s beginning and ending are decided every year in Knesset, so we, the sysadmins, every year have to update our environment with the new settings.

Since 2005 a law exists that regulates the beginning and end of the DST period in Israel. The law tells us when the DST period begins based on the international calendar, but because of religious reasons, the exit point of the DST is based upon the Hebrew lunar calendar (the DST always ends at 2 AM on a Sunday between Rosh Ha’Shana and Yom Kippur Hebrew holidays).

This year’s dates are:

Beginning: Last Friday of March, or March 30th, 2006 at 2 AM

End: Sunday, October 1st 2006 at 2 AM

Note for Exchange users: Make sure you read the Calendar Issues later in this article BEFORE applying any changes.

Note for Windows Vista users: Using the following method on the latest (or any, I didn’t check) build of Windows Vista might cause some issues with the time zone settings. You will need to import the following REG file instead.

Method #1 – Tzedit

The common practice is to use tzedit.exe utility from the NT4/Windows 2000 Resource Kit, which updates the registry on the machine you run the tool on. This is particularly important in international organizations which have branch offices in Israel, or Israeli companies that have branches in other time zones.

You will need to run the tool on ALL the computers in your network. No, running it on the DCs and servers alone won’t do.

Method #2 – A Registry file

You could import the following REG file instead of using Guy’s TZ2006 tool, however you will need to find a method of importing it to all your network computers.

Using this method is relatively easy, but you’ll need to configure a logon or startup script of some sort for the computers to perform the importing of the REG file.

Method #3 – TZ2006

As in 2005 (read Summer clock in Israel for 2005), Guy Teverovsky, an Israeli Directory Services MVP (webmaster and moderator of our AD Forum) has created a utility that will help sysadmins in making the change to the Jerusalem Time Zone more easily.

Using this utility allows the administrator to “push” the time zone settings to all the network computers without having to configure logon or startup scripts.

Like last year, Guy has created a tool called TZ2006 (5 kb). The application requires .NET Framework, which you can get from HERE.

Running the executable without arguments will update localhost to new Daylight Savings set

tings.

You can update a remote host by running something like:

PowerShell

1

C:\>tz2006.exe myserver

Or you can restore the Microsoft’s original settings by running:

PowerShell

1

C:>tz2006.exe myserver/restore

Some caveats:

You need .NET Framework on the computer you are running the application from. Updating remote hosts does not require .NET framework on remote hosts.

Because this is .NET code, it has to be executed from local drive or it will throw an exception about missing privileges, hence if you are intending to put it in logon/login/startup script, make sure to copy the EXE to the client and execute it from local drive.

The application forces “Jerusalem (GMT+2)” time zone on the client.

You need to run the application from local hard drive. .NET applications invoked from network drive run with restricted privileges.

If you are updating remote host, your account has to have write access to the relevant keys (being in Administrators group of the remote host is more than enough) and Remote Registry service has to be running on the remote host (duh!!)

The tool will not work on Windows 9x clients – do not even try ! I do not work with those and have not tested the application on 9x. Sorry, get yourself a real OS.

Refreshing the Time Zone settings on the client computers

You need to refresh the TZ settings on the client computers in order for it to take effect. You can do so by using one of the following methods:

Reboot the machines

If the users that are logged on to the machines have local admin rights they can run the following command:

PowerShell

1

w32tm/resync

If the users that are logged on to the machines have local admin rights they can temporarily change the Jerusalem Time Zone to something else (whatever comes first), click on Apply, then return to Jerusalem.

Updating many clients at once

If you want quick and dirty way to update some remote hosts in the AD, you can wrap the app with a simple batch script:

Again, copy the above text into a new .BAT file and do not forget to change the LDAP search base to reflect the target AD.

Important note: Please test it before running against some several hundred hosts. We have tested it on several computers and the 2005 version Guy has written last year has been proven to do the trick, but there is always a chance of some stupid error or unexpected client behavior (i.e. we have no idea what will happen to guest OS-s when updating WMWare or VS host).

Calendar Issues

Because of the different Israeli DST timeframe each year, Israeli users face an issue with recurring appointments and scheduled meetings in their Exchange and personal calendars.

Only appointments that are created after the new time zone has been applied will be displayed as expected during the overlap period. Any appointments that are created before a new operating system time zone has been applied will be displayed incorrectly during the overlap period.

Before applying this fix or any other registry-based fix please make sure you hard-print your calendar. You don’t need all of it, just the next 6 moths. Saving a backup copy won’t do because after you make the changes, any time you will open the backup version it will also be affected by the changes in the DST.

The problem

All meetings and scheduled appointments that fall between the following dates (overlap period) will be moved one hour ahead of the original time the meeting was scheduled:

March 31 to April 6 2006

Here is a screenshot of these dates BEFORE the change:

Here is a screenshot of the same dates AFTER the change:

All meetings and scheduled appointments that fall between the following dates will be moved one hour prior to the original time the meeting was scheduled:

October 1 to October 7 2006

Here is a screenshot of these dates BEFORE the change:

Here is a screenshot of the same dates AFTER the change:

The solution

After performing the changes in the DST for 2006 you will need to modify the appointments that were shifted. Microsoft recommends that you modify any appointments that were created during the overlap period in successive years by using either of the following methods:

Export the appointments to a .csv file before you modify the operating system time zone, delete existing appointments in the overlap period, and then re-import them after the operating system change. For more information about how to change the time zone without changing appointment times in Outlook, see the Microsoft Knowledge Base articles that are listed at the end of this section.

Manually modify each appointment in the overlap period in each successive year after the operating system time zone has been changed back.

Navigate to the above dates and make the necessary changes in the calendar by manually shifting the appointments one hour back or one hour forward, based upon the original time these appointments were scheduled to take place. You must instruct your users to perform this task, or use an automated method that invokes scripts and edits the user’s calendars. Because the time difference is only one week, unless your network consists of hundreds of clients I suggest you perform the task manually.

Support

No support of any sort will be given for this script/tool or for any other script/tool found on the Petri.co.il website for that matter. If you need to contact us with any support issues, feedback or suggestions regarding the tool(s) and script(s) found on this page please write an e-mail to THIS address.