Confused by r_normal_tz

Hi,

In a production docbase, r_normal_tz is set to 3600. We have observed that all audit trail entries are offset one hour forward: if I do a check in at 13:57, the dm_checkin even in the audit trail will be timestamped at 14:57. Content server, web server and client are all located in the GMT+1 timezone.

I read in another discussion in this forum that "r_normal_tz - should be set as the difference between the timezone of the Content Server and the GMT timezone, in seconds". That would mean that it's correctly set on my docbase, but then why are the time stamps wrong?

Is it also correct that offset is added at storage in the database, so that, if I wanted to correct it, I'd have to substract one hour to every single time value in the database? Is there a method to make this easier?

Thanks!

Message was edited by: mrgou (corrected a typo)

Find more posts tagged with

Comments

dnvhariprasad

which client are you using to verify the timezone? if you are using DA or webtop, consider the url for timezone..

mrgou

We're using Webtop, but it isn't in dqMan.

I'll have someone from a different timezone check. So, if my Content Server in at GMT+1, is it correct that r_normal_tz = 3600 ?

dnvhariprasad

yes..

DCTM_Guru

"is it correct that r_normal_tz = 3600?"

- This 6 hr offset, not 1 hr offset. Are you users in different timezone then your servers (ie GMT+1).

mrgou

Errrr, 60 secs x 60 mins = 3600.

I am at the same timezone as the Content Server when I get those results. However, I've asked an EST-based user to try and see if the results are similar (i.e. audit trail entries displayed in Webtop bumped up by one hour).

DCTM_Guru

Sorry for the confusion, I havent had my coffee yet

FYI - dmfTzoff parameter is in min (not sec). This is where my confusion probably stem from.

Have you read Scott Roth's blog about this:

http://msroth.wordpress.com/2012/11/12/time-zone-technical-notes/

mrgou

Thanks, I'll check this. I had a US-based user try as well, and he had the same thing: an activity he performed at at 10.31am EST shows up in the audit trail as 11.31EASST...

RFCVA

What

Documentum’s UI timestamp type/format is different from Oracle’ 12c time type/format. In Documentum the time is presented in the UI as UTC times instead of UTC – 7 hours to represent Arizona time (in my case).

Date values

By default, Content Server stores date values as UTC (Coordinated Universal Time) time in new repositories (Documentum 6 and later), and as the local time in repositories that are upgraded from before version 6.

The r_normal_tz property in the docbase config object controls how Content Server stores dates in the repository. If the property value is 0, all dates are stored in UTC time. If the property contains an offset value, dates are normalized using the offset value before being stored in the repository. Offset values must use a time zone offset from UTC time, expressed as seconds. For example, if the offset represents the Pacific Standard Time zone, the offset value is -8*60*60, or -28800 seconds. When the property is set to an offset value, Content Server stores all date values based on the time identified by the time zone offset.

In a Documentum 6 or later repository, r_normal_tz value is set to 0. In a repository upgraded from a release earlier than version 6, the r_normal_tz value is set to the offset that represents Content Server local time and cannot be changed. (pages 105 & 106, Documentum Content Server 7.2 – Administration and Configuration Guide.pdf)

Analysis

The value is stored in the docbase_config object, which translates to a table called “dm_docbase_config_s”; this means it is possible to update the value either via DQL or SQL.

DQL Update statement

Based on the documentation, to update the “r_normal_tz” value for the Arizona Time Zone (-7*60*60 ) as the value store the differential in seconds, this is how the DQL statement would look like:

Update dm_docbase_config Object Set r_normal_tz = -25200

After updating the value, restarting the repositories would be necessary.

Note: Please mark this question as answered by me

PanfilovAB


Note: Please mark this question as answered by me

haha, documentum recognises only two states of r_normal_tz: zero and not zero