The Content Server and Time Zones

I had a client who, every time they connected to the Docbase with their custom app, received results that showed r_creation_dates and r_modify_dates that were hours off.  That in itself was puzzling, but the fact that the returned times were always exactly 5 hours off was more so.  My first thought (and probably yours) was that the server was in a different time zone, or at least thought it was.  Nope, the server was configured for Eastern Standard Time as was my client’s local workstation.  It turned out, it was a time zone problem, but not like I expected.

Starting in D6, the Content Server stores everything using UTC (GMT-0) time.  The client is responsible for converting the UTC time to local time.  D6 clients do this automatically by negotiating with the Content Server when they connect.  (They use the dfc.time_zone value in the file, which is copied from the JVM property.)  If you examine the URL for Webtop, you will notice a variable similar to dmfTzoff=300 tacked on at the end.  This is telling the server that this client is 300 minutes (5 hours) behind UTC; that’s how the times are corrected for local viewing.  (If you are in Pacific Standard Time, you will see something like dmfTzoff=540.)  However, since my client was using a custom application that was written for Documentum 5.3, and didn’t do any kind of time conversion, they got back raw UTC times.  You can experience this phenomenon by viewing an object using a database client (see here for suggestions)  and comparing its attributes to the same object viewed from Webtop.  Or, if you have an old 5.3 client laying around, connect it to your D6 Docbase.

Time zone behavior is governed by two attributes of the dm_docbase_config object:  r_tz_aware and r_normal_tz.  By default, r_tz_aware = T and r_normal_tz = 0.  This means that all times will be stored as UTC times and converted to client local time when they are displayed.  To revert to pre-D6 functionality, that is, storing the actual server local time in object attributes, set r_tz_aware = F and set r_normal_tz = <server off set in seconds>.  For example, if your server is in Eastern Standard Time, r_normal_tz = -18000.  Restart the server for this change to take effect.

UPDATE:  There is an interesting discussion on the EDN relevant to this post and TaskSpace.  Notice the resolution at the end of the discussion.


About Scott
I have been implementing Documentum solutions since 1997. In 2005, I published a book about developing Documentum solutions for the Documentum Desktop Client (ISBN 0595339689). In 2010, I began this blog as a record of interesting and (hopefully) helpful bits of information related to Documentum, and as a creative outlet.

3 Responses to The Content Server and Time Zones

  1. Ed Hunt says:

    We ran into an interesting issue related to this, users had created desktop shortcuts to Webtop by dragging a link from the browser, the link was dmfTzoff=300. Then daylight savings time came around and the time was dmfTzoff=240, these users would still get the 5 hour offset instead of four when they opened Webtop from the link. This caused document times to start jumping around all over, since one time it may be checked in by someone using a five hour offset, and others checked in by a four hour offset. Took me two weeks to figure out why the system seemed to be using random times..


  2. Pingback: Time Zone Technical Notes « dm_misc: Miscellaneous Documentum Information

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: