Microsoft Daylight Saving Time & Time Zone Blog : Other Products

Q: Updates to Microsoft Office 2004 for Mac 11.3.7 update and Entourage?

atsim — Thu, 13 Sep 2007 07:35:03 GMT

Q: I checked http://support.microsoft.com/gp/dst_prodlist#Ent and under Entourage it states to download Microsoft Office 2004 for Mac 11.3.7 update.

I checked the KB for the update and it mentioned nothing about DST. I checked the readme for the download and it updates the following 3 files:

Microsoft Component Plugin
Microsoft Excel
Microsoft Ole Automation

Can someone explain how updating to Mac 11.3.7 updates Entourage for DST this Fall?

A: The Entourage product group has noted that the download for the Microsoft Office 2004 for Mac 11.3.7 Update includes most recent updates including the most recent changes to DST update as of August 31, 2007.

Product updates are cumulative, and customers should visit the Office 2004 download page for the latest product information and updates.

See the MacBU's team blog post on the subject at http://blogs.msdn.com/macmojo/archive/2007/01/10/the-times-they-are-a-changin.aspx (as noted earlier here).

[M3]

Calendar appointments showing 1 hour later on recipients' calendar appointments

atsim — Mon, 12 Mar 2007 22:06:00 GMT

Symptom: Any calendaring client may show 1 hour later on a recipients' calendar appointment (Outlook, OWA, Blackberry or Goode devices etc.). The recipient will appear to not follow DST2007 rules. This is true even with OS patches are successfully applied even with rebasing successfully executed. Warning: If the system is not OS-patched or rebased successfully, the symptoms will appear similar to this issue (and the unpatched OS is much more common).

· Explanation: This is caused due to multiple copies of CDO.dll or CDOEX.dll existing on the Exchange and/or BES/Goode servers , and the copy of CDO.dll or CDOEX.dll is not being updated, but the applications (Outlook, OWA, Blackberry, Goode, etc) are using the older version of the dll. This can be created by several applications (unrelated to messaging potentially) which install or copy CDO.dll or CDOEX.dll to a separate directory, then register that rough dll.

· Solution:

o Determine if you have this specific issue,

§ please verify all patches and rebasing issues are successfully applied (for example is the OS clock correct, are meetings the user organized being rebased successfully). If the systems are not properly patched or rebased, the symptoms may appear similar.

§ Verify that if a user who is patched sends an appointment to another user who is patched, that the recipient user is showing that appointment one hour later than originator’s.

§ Search the Exchange server (and BES server etc) for multiple copies of CDO.dll or CDOEX.dll.

1 - Run this: C:\>dir /s cdo.dll

2 - Repeat for all drives.

3 - If there's more than one cdo.dll, you have a problem

Same for cdoex.dll

o Fix:

Exchange 5.5 (CDO.dll only - 5.5 does not use/ship CDOEX.dll)

(note - path to system32 may vary)

1 - c:\winnt\system32\cdo.dll is the correct CDO.dll. Delete all other copies of CDO.dll.

2 - regsvr32 "c:\winnt\system32\cdo.dll"

Exchange 2000/2003 CDO.dll

(again - paths may vary slightly depending on installation)

1 - c:\program files\exchsrvr\bin\cdo.dll is the correct CDO.dll. Delete all other copies of CDO.dll.

2 - regsvr32 "c:\program files\exchsrvr\bin\cdo.dll"

Exchange 2000/2003 CDOEX.dll

1 - c:\Program Files\Common Files\Microsoft Shared\CDO\CDOEX.dll is the correct CDOEX.dll. Delete all other copies of CDOEX.dll.

2 - regsvr32 "c:\Program Files\Common Files\Microsoft Shared\CDO\CDOEX.dll"

Time Zones not updating on Windows 2003, Windows XP or Windows 2000

atsim — Mon, 12 Mar 2007 01:31:00 GMT

After applying 931836 time zone changes don’t take effect until you manually change the time zone

Symptom: We have isolated reports that Windows 2000, XP, and 2003 may find that their Windows clocks do not move forward for DST, even with fixes applied from 931836 or 928388.

· Explanation: The root cause of this issue is still under research, but we believe we can attribute the issue to customers manually applying the time zone updates using the TZEdit application, referring to the steps in KB 914387. It appears that the registry appears to have been altered by some other means (this part is under investigation but could include not completing 914387 or modifying TZ parameters with TZEdit, or potentially malware detection software). This will be updated as research advances.

· Solution:

o Determine if you have this specific issue,

§ Is the OS’s system time not advancing for DST?

§ Open the Time/Date control panel applet and changing the time zone to a new time zone; hitting apply, and changing it back to the original time zone will often correct this problem. This provides confirmation the hotfix was applied, but seems to bypass the aspects involved which prevent the application of the hotfix.

Several customers have confirmed the script below addresses the issue, once it is confirmed to be this specific issue.

Detail:

You may see systems that have successfully applied the Windows DST2007 hotfix 931836 but are still operating on old DST rules after March 11. Opening the Time/Date control panel applet and changing the time zone to a new time zone; hitting apply, and changing it back to the original time zone will often correct this problem. If this is the scenario you are seeing, you can run the following script after the hotfix is applied to automate the process of changing the time zone and ensure that the system runs with update DST2007 rules.

Set objSh = CreateObject("WScript.Shell")

'Get the StandardName key of the current time zone

szStandardName = objSh.RegRead("HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\StandardName")

'Enumerate the subkeys in the time zone database

const HKEY_LOCAL_MACHINE = &H80000002

Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")

szTzsKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones"

objReg.EnumKey HKEY_LOCAL_MACHINE, szTzsKeyPath, arrTzSubKeys

'Step through the time zones to find the matching Standard Name

szTzKey = "<Unknown>"

For Each subkey In arrTzSubKeys

If (objSh.RegRead("HKLM\" & szTzsKeyPath & "\" & subkey & "\Std") = szStandardName) Then

'Found matching StandardName, now store this time zone key name

szTzKey = subkey

End If

If szTzKey = "<Unknown>" Then

'Write entry to the Application event log stating that the update has failed to execute

objSh.LogEvent 1, "DST 2007 Registry Update and Refresh failed to execute on this computer. Time zones failed to enumerate properly or matching time zone not found."

Wscript.Quit 0

End If

Dim process, processid, result, strUpdateCommand

Set process = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2:Win32_process")

'Add time change privilege to the process object

process.Security_.Privileges.AddAsString "SeSystemTimePrivilege",True

strUpdateCommand = "control.exe timedate.cpl,,/Z" & szTzKey

'Launch control.exe to refresh time zone information using the TZ key name obtained above

result = process.create(strUpdateCommand,Null,Null,processid)

If result <> 0 Then

objSh.LogEvent 1, "DST 2007 Registry Update and Refresh failed to execute on this computer. Unable to refresh the Timezone database."

Wscript.Quit 0

End If

'Get current display name of refreshed time zone

szCurrDispName = objSh.RegRead("HKLM\" & szTzsKeyPath & "\" & szTzKey & "\Display")

'Write entry to the Application event log stating that the update has executed

objSh.LogEvent 4, "DST 2007 Registry Update and Refresh has been executed on this computer." & chr(13) & chr(10) & chr(13) & chr(10) & "Current time zone is: " & szCurrDispName & "."

On the File menu, click Save As.

Select a destination, and then type refreshTZinfo.vbs in the File name box.

In the Save as type box, click All Files, and then click Save.

Another variation of this problem has been observed on Windows 2000. In that scenario after applying the DST hotfix or using TZEdit and then changing the time zone (manually or with the script above), the time zone still does not update. For that situation we’ve found that making the registry updates described in 914387 followed by running the script above will reliably cause the system to follow the new DST2007 rules. A symptom you may observe is that if you set the clock to the correct time, it will revert back to the incorrect time within one hour.

Additional information for reference:

Hotfix 931836 has three steps during the install:

1) Hotfix adds registry keys for new time zones, dynamic DST, and time zone version number

2) TZChange.exe updates existing time zones, and adds the values for the new time zones.

3) If the time zone being updated is the time zone the system is on, it calls the API function SetTimeZoneInformation() to update the information that the kernel reads at startup in the registry. After this, it updates a structure in the system that contains this information as well as send out a WM_SYSTEMSETTINGSCHANGE message to running applications

The first problem described above seems to be happing during step #3. Reasons for this failure may be related to security rights (this is still under investigation). The first two steps only require write access to HKLM\Software\Microsoft\Windows NT\CurrentVersion which by default is given to Administrators and Power Users. By default these same two groups have the “Change System Time” user right granted which is needed for step #3.

The following problems have been confirmed when installing the DST2007 patch KB931836:

1. Time Zones registry database was modified before the patch was applied. To check for this, export the Time Zones key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones) and compare it to a known unpatched system. The key can also be manually verified by checking the TZI value under an affected time zone subkey. The value is in the following C format.

        typedef struct _REG_TZI_FORMAT
        {
            LONG Bias;
            LONG StandardBias;
            LONG DaylightBias;
            SYSTEMTIME StandardDate;
            SYSTEMTIME DaylightDate;
        } REG_TZI_FORMAT;

The StandardDate and DaylightDate fields can be checked for the old or new DST rules.

2. Update.exe failing to run. In this case check if any Microsoft update package installs correctly. If other update packages also have problem then there is a problem with the update engine. Start with http://support.microsoft.com/kb/906602 to begin troubleshooting this issue.

3. Antivirus software interfering with install. Disable antivirus software on a test client and see if the install then works.

4. Incomplete registry update from TZEdit or OS patch (usually on Windows 2000). This can be permissions related. If following the steps from 914387 resolves the problem, this may be the cause of the failure.

The following problems have been confirmed on patched systems that display the incorrect time:

1. Client/Server based solutions such as Novell and Altiris may synchronize the client local clock with the server local clock. Ensure that the time server has also been updated with DST2007 patches.

2. Some third party applications that manually adjust the time may depend on the C run-time library. Ensure that machines that run such applications have been updated with hotfix KB 932590 (http://support.microsoft.com/kb/932590).

Applications using historical data from 2006 (or any previous years) can have invalid results

atsim — Sun, 11 Mar 2007 12:39:00 GMT

Executive Summary:

Applications using historical data from 2006 (or any previous years) can have invalid results. Microsoft is currently working to provide support for vendors and software developers for their applications, if the application does not provide historical DST start and end-date tables. The change in DST start-time was something applications on top of Windows could address, or not, by maintaining a historical DST-Change date to do this conversion (for countries like Israel). However, this had not been an issue in the USA previously, as DST had always started on the same day, prior to 2007. Windows provides the functionality to allow the operating system to address this, starting in Vista.

Example:

If a financial application accesses financial data from previous years which are stored within SQL, that application’s results can be incorrect. The application’s query results (or stored procedures) may fail or return invalid dates for periods before 2007 (any year with the older DST-start/end dates). For explanation on DST’s affect on time stamps in Office, see this article:

http://office.microsoft.com/en-us/help/HA102201961033.aspx

Detail

SQL Server DST and DateTime

With details below to expand on the following, it is easiest to summarize by saying that SQL server stores datetime ignorant of DST. Key points to consider are that:

· SQL Server does not manipulate datetime.

· The datetime value is stored as is with no modification on the part of SQL Server during insert/update/select.

· When running applications that appear to have results that have a manipulated the date, investigate the business logic in the stored procedures/selects/middleware/client applications.

· Also keep in mind that SQL is unaware of its physical or time zone location, with a base of users that could be global and in dozens of time zones SQL will accept any valid time remaining unaffected by DST rules of the host server or accessing client.

· SQL Server does not store datetime as an EPOCH/POSIX style.

Why SQL does not alter Datetime

The basic rules of relation databases ACID;

The one property of ACID (Atomicity, Consistency, Isolation, Durability) is Durability. If SQL manipulates the data on the way in/out of the database it is a violation of standards of a stable RDMS. So if SQL changes your date, it would not be Durable and would violate the standards of a stable RDMS. The version of standards for ACID can be viewed in ISO/IEC 10026-1:1992 Section 4; and MS SQL Server follows this standard. So for SQL to violate that standard would be a significant departure from ISO standards. Business logic contained within the application, or stored procedures, middle ware, or an additional application layer function may choose to maintain a change table for DST dates, without violating the ISO standards. This holds true for any RDMS, that wants to comply with standards set forth in ISO/IEC.

Ref: http://en.wikipedia.org/wiki/ACID

In relation to SQL Datetime compared to EPOCH/POSIX time on UNIX;

SQL DateTime

Values with the datetime data type are stored internally by the SQL Server 2005 Database Engine as two 4-byte integers. The first 4 bytes store the number of days before or after the base date: January 1, 1900. The base date is the system reference date. The other 4 bytes store the time of day represented as the number of 1/300-second units after midnight.

Ref: http://msdn2.microsoft.com/en-us/library/ms187819.aspx

UNIX EPOCH/POSIX time

Whereas EPOCH/POSIX time is based on number of seconds since midnight January 1, 1970, not counting leap seconds stored as an integer value. This is NOT a true encoding of UTC since UTC does account for leap seconds.

Ref: http://en.wikipedia.org/wiki/Unix_time

GETDATE() Function

The GETDATE() function requests the date and time from the local Host Operating System regardless of time zone and presents the server time to the calling T-SQL. No time or date manipulation is done on the request.

REF: http://msdn2.microsoft.com/en-us/library/ms188383.aspx

GETUTCDATE()

The GETUTCDATE() returns the datetime value that represents Coordinated Universal Time or GMT. The current UTC is derived from the current local time and time zone data (or bias) on the SQL Server host computer. GETUTCDATE() should not be confused with “EPOCH UTC” time, they are not the same, see the link below for details.

Ref: http://msdn2.microsoft.com/en-us/library/ms178635.aspx

DATEDIFF() & DATEADD() Functions

These two SQL datetime functions are not timezone or DST aware. When application uses these datetime functions to manipulate datetime data, application developers need to

make sure correct timezone and DST are applied before saving the result to the database.

Ref: http://support.microsoft.com/?id=931975, "How to prepare SQL Server 2005 and SQL Server 2000 for changes to daylight saving time in 2007"

Is Cisco MeetingPlace impacted by DST and how do they rebase meetings?

atsim — Sat, 10 Mar 2007 07:10:00 GMT

Q: Is Cisco MeetingPlace impacted by DST and how do they rebase meetings?

A: It’s our understanding that MeetinPlace leverages the core OS for the DST information, so that they are fine once the underlying Windows 2000 Server is patched. We understand that Cisco has a tool that will convert all the currently scheduled meetings on the MeetingPlace server and any new meetings scheduled after the OS is patched are handled properly.

Cisco also recommends to their users to make sure to patch Exchange as well if it is being used as the front end scheduler. For these users, they also need to patch the MeetingPlace Outlook gateway server after they’ve patched the Exchange Server (the user copies the CDO.dll from the Exchange server to their gateway server).

Here is the notice from Cisco’s website.

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_field_notice09186a00807dcf40.shtml

Also, of interest, here is the Unity notice as well.

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_field_notice09186a00807dcf40.shtml