Select the product you need help with

XsltListViewWebPart and ddwrt:DateTime limitations

Article ID: 2580994 - View products that this article applies to.

Symptoms

In Microsoft SharePoint Foundation and Microsoft SharePoint Server, the primary view technology is the XSLTListViewWebPart. Users can customize the XSLT by using Microsoft SharePoint Designer.

For backward compatibility, the ddwrt:DateTime function is available. However, it can produce inconsistent results if it is used inside the XSLTListViewWebPart Web Part.

For example, a user might add the following markup inside XSLTListViewWebPart:

<xsl:value-of select="ddwrt:FormatDate(string($thisNode/@*[name()=current()/@Name]),1033,3)" />

If the user who accesses the page is located in the United States, and the date that is being formatted is 1/2/2011, the date is displayed correctly. However, if the user is located in the United Kingdom, the date is displayed incorrectly. In this case, "Tuesday, February 01, 2011" is incorrectly displayed instead of "Sunday, January 02, 2011."

Back to the top | Give Feedback

Cause

This problem occurs because the ddwrt:FormatDate function expects the data format to be UTC, but XSLTListViewWebPart instead returns the date as preformatted to the web locale or to the locale date and time.

Back to the top | Give Feedback

Resolution

To resolve this problem, use the new EnableOriginalValue property that was added to the XlstListViewWebPart Web Part that unblocks this scenario. The previous workarounds are still valid until the February 2012 Cumulative Update is installed. For more information about the update, click the following article number to go to the article in the Microsoft Knowledge Base:

2597132

(http://support.microsoft.com/kb/2597132/ )

Description of the SharePoint Foundation 2010 cumulative update package (SharePoint Foundation server-package): March 7, 2012

After you install this update, you must set the EnableOriginalValue property to True. The default value is False.

Note This setting slows down the rendering of the view because the server will have additional processing responsibilities. After the EnableOriginalValue property is set to True, you must change the XSLT to include the .ISO8601. To do this, use the following code:

<xsl:value-of select="ddwrt:FormatDate(string($thisNode/@*[name()= concat(current()/@Name, '.ISO8601')]),1033, 3)" />

Back to the top | Give Feedback

Workaround

To work around this problem, you can use any of the following methods if you have not yet installed Cumulative Update 2597132

(http://support.microsoft.com/kb/2597132/ )

Use the native functionality that is built into the XSLTListViewWebPart Web Part. The Web Part respects the locale configurations in the site, and presents the data accurately. however, it will not have the formatting offered by the ddwrt:DateTime function.

Create a calculated column that uses a formula that resembles the following:

=TEXT(date,"dddd")&", "&TEXT(date,"mmmm")&" "&TEXT(date,"dd")&" "&TEXT(date,"yyyy")

Use the DataFormWebPart Web Part together with the UseServerDataFormat property set to False on the <SPDataSource> tag.

For more information about the UseServerDataFormat property, go to the following MSDN article:

SPDataSource.UseServerDataFormat property

(http://msdn.microsoft.com/en-us/library/ff412418.aspx)

When the UseServerDataFormat property is set to False, the DataFormWebPart Web Part receives the date/time information in UTC format. Therefore, the ddwrt:FormatDate function work correctly.

Back to the top | Give Feedback