As we mentioned earlier in the year, we have many clients looking to push content out of Documentum for consumers. We are currently deploying this type of application for a client with specific requirements in how to display the date in the consumer interface. For many of our web applications, we leverage client utilities (YUI, GWT, etc) to expedite the user interface development. During testing of the application, we uncovered a bug that was easily fixed but the root cause of the issue is something to keep in mind as you are building web applications and relying on client side processing to generate information.
Our search result screen displayed a date and leveraged the Java application server to parse and format the date object to display to users in the GMT time zone.
We display the same date in a YUI panel which leveraged client-side JavaScript to parse and format the date in the CDT time zone.
As you can see, the application was showing two different dates for the same document. Since the official timestamp of the document fell within the 5 hour window and we were using two different time zones to interpret the date, the date was a day off in the CDT zone. While the fix for this was straightforward (we adjusted the client side driven date to be GMT) the ramifications of a date mismatch in a production environment are major.
These types of issues are easily overlooked during development and testing phases because development environments typically have clients/servers set up in the same location and time zone. This reinforces that when defining requirements, it is important to consider all factors, even something as simple as time zones.
Leave a Reply