 |
If you are connecting to SQL Server 2005 you will need to deploy the QuickObjects TimeZone assembly for SQL Server 2005. Please contact support@akaltech[Replace_This_No_Spam_Tag].com if you need help in installing/configuring the SQL Time Zones library. |
TranslateTimeZones is a property on the BaseBusinessObject, and it is used to specify if the business object will automatically transform all date times for time zone difference between the user's time zone and the UTC.
<appSettings>
<add key="TranslateTimeZones" value="True" />
</appSettings>
Setting the value as shown above will cause all the business objects to convert the date time values to UTC before saving and while selecting the values will be translated to the user's time zone (time zone key is stored in LocalTimeZone property of the business object).
This is only necessary if your application requires representation of date time values in different time zones. In such applications it is considered best to store all the date time values in UTC. This means that every time a date time needs to be saved to database record it must be transformed from the user's specified date time to its equivalent UTC time. This calculation is currently provided by .NET Framework. However, as of now Microsoft Windows operating system and .NET framework can only perform day light time savings (DST) calculations based on one rule set. Since the DST rules have changed for the US starting 2007 you will need to apply a patch from Microsoft to get these calculations to work correctly for the current year.
This however still leaves a big problem, and that is the ability to calculate time zone differences correctly for previous years. This problem is very easily solved by integrating the business objects with the TimeZones component. To utilize the TimeZones, all you need to do is add a reference to it in your project. If you are using SQL Server 2005 you can also deploy the TimeZones assembly for SQL 2005.
|
If you are using Oracle (any version) or SQL Server 2000 this setting will be ignored during any SELECT command. Essentially the returned date time data will contain the original values that are stored in the database. It will however use this setting in the WHERE clause or in INSERT and UPDATE commands. You will need to go through the results you get and transform all the dates and which can also be very easily done. In SQL Server 2005 you can deploy the TimeZone component built specifically for SQL Server 2005 and hence the data returned by a SELECT statement can already have their date time fields transformed with the current time zone. |