Last updated on MARCH 02, 2017
Applies to:Siebel CRM - Version 8.1.1  and later
Information in this document applies to any platform.
Using Time Zone (non GMT) in the Siebel Application that includes the Daylight Time Saving (DST) events (half-yearly changes to/from Summer time).
Application Session which is working during the DST event
then Business Component's "Created" and "Last Updated" system fileds will be populated with timestamp which is NOT considering the DST delta.
The issue occurs during 1 hour after DST. As result Business Component records getting improperly stamped (have DST time difference to the actual time).
1. On Siebel Application OS machine:
a) set Siebel Application OS time zone to "UTC" (no DST)
b) set Siebel Application OS date to the "26th October 2014"
- it was key day of ending DST in British Summer Timer (BST) in 2014.
2. Open Siebel Client session, logining in as some user:
a) check/set that the user User Preference - "time zone": is set to "(GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London"
- it is the BST TZ (has DST change on the 26.10.2014)
b) check/set that the System Preference "Universal Time Coordinated" is set to "TRUE"
c) re-login (logout + login), if user /system preferences mentioned above were updated
3. On Siebel Application OS machine:
- set Windows OS system time to "00:20:00" (UTC) - before the DST event that ends BST
4. In the Siebel Client session:
a) navigate to accounts list view
b) create and commit new account named as "T0"
5. On Siebel Application OS machine:
- set Windows OS system time to "01:20:00" (UTC) -- after the DST event that ends BST
6. In the Siebel Client session:
- create and commit new account named as "T1"
7. Use open direct DB tool (e.g. odbcsql) connected to the DB instance of the Siebel Enterprise:
a) run SQL-Query to retrieve UTC-timestamp from columns: created, last_upd and db_last_update of both accounts:
SELECT CREATED, LAST_UPD, DB_LAST_UPD, NAME FROM S_ORG_EXT WHERE NAME IN ('T0','T1');
b) see that for the 1st account ("T0"),created before DST event, all 3 columns have expected timestamp: "00:2x:00".
c) see that for the 2nd account ("T1"),created just after DST event,
- the DB_LAST_UPD column has expected timestamp: "01:2x:00".
- the CREATED and LAST_UPD column have UNEXPECTED timestamp: "02:2x:00".
The timestamp discrepance disappears an next data update (e.g. creating next account) in same session and also in the new session.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms