This technote identifies an issue that can occur in the IBM Rational ClearQuest Web client when the time zone offset for a date-time field is different from the user's current time zone offset because of Daylight Saving Time (DST) transitions.
When using the ClearQuest Web client version 7.1.x or 8.0, a query that has a submit date or date-time field shows the correct timestamp, but when printing or exporting the query result set to Microsoft Excel or to a text file, or when using the base ClearCase integration operations "ExecuteQuery" or "GetRecords," the timestamp may differ because DST changes were not taken into consideration by the server.
When the long date format user preference is set, the user's GMT offset is provided with every date-time value, instead of the time zone abbreviation appropriate for each date time value.
This issue is identified as a product defect under APAR PM08377.
Resolving The Problem
This problem has been fixed in IBM Rational ClearQuest Web version 184.108.40.206.
When the user logs in, the ClearQuest Web client now determines when their DST transitions occur and from that finds the IANA time zone identifier. This time zone is used for Export and Print procedures and for base ClearCase "ExecuteQuery" and "GetRecords" operations.
When the long date format preference is set, ClearQuest Web 220.127.116.11 includes an appropriate time zone abbreviation with date-time values (such as "EDT") instead of the user's current time zone offset (such as "GMT+4:00").
The user's time zone and offset are also made available to hooks through the session variables "_CQ_WEB_TIMEZONE" and "_CQ_WEB_TZOFFSET". For example, the following hook code retrieves the user's time zone ID and their current time zone offset:
$timezoneID = $session->GetNameValue( "_CQ_WEB_TIMEZONE" ); // e.g. "America/Detroit"
$gmtOffset = $session->GetNameValue( "_CQ_WEB_TZOFFSET" ); // e.g. "GMT-4:00"
Was this topic helpful?
01 August 2018