This documentation is archived and is not being maintained.

DateTime XAML Syntax

Some controls, such as Calendar and DatePicker, have properties that use the DateTime type. Although you typically specify an initial date or time for these controls in the code-behind at run time, you can specify an initial date or time in XAML. The WPF XAML parser handles parsing of DateTime values using a built-in XAML text syntax. This topic describes the specifics of the DateTime XAML text syntax.

This topic contains the following sections.

Setting dates in XAML is not always necessary and may not even be desirable. For example, you could use the DateTime.Now property to initialize a date at run time, or you could do all your date adjustments for a calendar in the code-behind based on user input. However, there are scenarios where you may want to hard-code dates into a Calendar and DatePicker in a control template. The DateTime XAML syntax must be used for these scenarios.

DateTime XAML Syntax is a Native Behavior

DateTime is a class that is defined in the base class libraries of the CLR. Because of how the base class libraries relate to the rest of the CLR, it is not possible to apply TypeConverterAttribute to the class and use a type converter to process strings from XAML and convert them to DateTime in the run time object model. There is no DateTimeConverter class that provides the conversion behavior; the conversion behavior described in this topic is native to the WPF XAML parser.

You can specify the format of a DateTime with a format string. Format strings formalize the text syntax that can be used to create a value. DateTime values for the existing WPF controls generally only use the date components of DateTime and not the time components.

When specifying a DateTime in XAML, you can use any of the format strings interchangeably.

You can also use formats and format strings that are not specifically shown in this topic. Technically, the XAML for any DateTime value that is specified and then parsed by the WPF XAML parser uses an internal call to DateTime.Parse, therefore you could use any string accepted by DateTime.Parse for your XAML input. For more information, see DateTime.Parse.

Important noteImportant

The DateTime XAML syntax always uses en-us as the CultureInfo for its native conversion. This is not influenced by Language value or xml:lang value in the XAML, because XAML attribute-level type conversion acts without that context. Do not attempt to interpolate the format strings shown here due to cultural variations, such as the order in which day and month appear. The format strings shown here are the exact format strings used when parsing the XAML regardless of other culture settings.

The following sections describe some of the common DateTime format strings.

Short Date Pattern ("d")

The following shows the short date format for a DateTime in XAML:


This is the simplest form that specifies all necessary information for typical usages by WPF controls, and cannot be influenced by accidental time zone offsets versus a time component, and is therefore recommended over the other formats.

For example, to specify the date of June 1, 2010, use the following string:


For more information, see DateTimeFormatInfo.ShortDatePattern.

Sortable DateTime Pattern ("s")

The following shows the sortable DateTime pattern in XAML:


For example, to specify the date of June 1, 2010, use the following string (time components are all entered as 0):


RFC1123 Pattern ("r")

The RFC1123 pattern is useful because it could be a string input from other date generators that also use the RFC1123 pattern for culture invariant reasons. The following shows the RFC1123 DateTime pattern in XAML:

ddd, dd MMM yyyy HH':'mm':'ss 'UTC'

For example, to specify the date of June 1, 2010, use the following string (time components are all entered as 0):

Mon, 01 Jun 2010 00:00:00 UTC

Other Formats and Patterns

As stated previously, a DateTime in XAML can be specified as any string that is acceptable as input for DateTime.Parse. This includes other formalized formats (for example UniversalSortableDateTimePattern), and formats that are not formalized as a particular DateTimeFormatInfo form. For example, the form YYYY/mm/dd is acceptable as input for DateTime.Parse. This topic does not attempt to describe all possible formats that work, and instead recommends the short date pattern as a standard practice.