Microsoft Daylight Saving Time & Time Zone Blog : Other Microsoft Products

KB 932395 updated: Commerce Server 2002, Commerce Server 2007 for DST 2007

atsim — Wed, 22 Aug 2007 06:54:00 GMT

Please note that for Microsoft Commerce Server 2002 and Commerce Server 2007, KB article 932395 has been updated.

This article outlines how to update these Microsoft products to meet the updated time zone changes (including the changes to observation of DST in New Zealand) as outlined in KB 933360, "August 2007 cumulative time zone update for Microsoft Windows operating systems."

APPLIES TO

•	Microsoft Commerce Server 2007 Enterprise Edition
•	Microsoft Commerce Server 2007 Developer Edition
•	Microsoft Commerce Server 2007 Standard Edition
•	Microsoft Commerce Server 2002 Standard Edition

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"

SBS 2003 w Exchange 2003 SP2, patched with KB 931836 and KB 926666, then rebooted: OWA clients see DST rules in TZ picker in both basic and premier client modes. I expect them to see new Pacific TZ in picker but they see DST 2006 version, Pacific + Tijuan

atsim — Thu, 08 Mar 2007 02:27:00 GMT

Q: SBS 2003 w Exchange 2003 SP2, patched with KB 931836 and KB 926666, then rebooted: OWA clients see DST rules in TZ picker in both basic and premier client modes. I expect them to see new Pacific TZ in picker but they see DST 2006 version, Pacific + Tijuana. What is wrong?
A: This behavior can occur if the client is not patched. Parts of the dialog rely on the client's time zone database for information.

So what relationship does this hot fix kb 932962 have to this kb 926666 in terms of CDO? What’s the difference? Also, what order does KB 932962 have to be deployed in as relates to OS DST KB 926666?

atsim — Thu, 08 Mar 2007 02:27:00 GMT

Q: So what relationship does this hot fix kb 932962 have to this kb 926666 in terms of CDO? What’s the difference? Also, what order does KB 932962 have to be deployed in as relates to OS DST KB 926666?
A: kb 932962 is the Outlook (client) version. kb 926666 is the Exchange (server) version. There is no connection between the two - one does not require the other. Each must be evaluated according to the need.

As kb 932962 (Outlook CDO update) is not installed by default, you may have to install it if you use applications such as ACT and InterAct (relationship management programs). These applications use CDO to access contact and calendaring information in Outlook. If you do not have programs like that, you do not need to apply 932962. For instance, if you run ACT (a contact manager program), it installs the Outlook version of CDO, and you should install kb 932962.

Microsoft SQL server 2000/2003 DST- If you are not using the Notification Service, do I need to worry about anything else except the OS patch?

atsim — Thu, 08 Mar 2007 02:27:00 GMT

Q: Microsoft SQL server 2000/2003 DST- If you are not using the Notification Service, do I need to worry about anything else except the OS patch?
A: No. OS patch only.

Hi, thanks for ignoring my question. Please tell me why I should patch SharePoint if I have no public calendars or exchange public folder linkages. I have seen no rationale for patching on any of the sites.