Client-side Date Format Localization in ASP.NET AJAX

Posted Fri Dec 1, 2006 @ 10:03 PM

Much buzz has already been created around new client-side localization features introduced with ASP.NET AJAX Beta 2. Most of it has focused on localized resources, which can now easily be retrieved from the server by client scripts. This makes sense - resources are arguably the most important aspect of localization. But not from a web control developer's point of view. When developing web controls, we deal with little actual content - for the most part, we are providing form for our customers' content. Having worked on ComponentArt.Web.UI Calendar control in particular, I was especially interested in localization features that deal with date and time formats.

How Calendar Works Today

In order for Calendar control to be customizable and culture-independent, we send information about date settings to the client, where the rendering is to take place. Examine the HTML source of a page that contains a Calendar control and you will see excerpts like these:


These are portions of JavaScript arrays with relevant date format information. They are put together by the Calendar control on the server, to be used by the control's rendering engine on the client. The original source of information is ASP.NET's System.Globalization namespace (unless, of course, the developer specifically instructs the Calendar control instance to use some custom date formats). It is the wealth of information in the framework that enables the Calendar to seamlessly switch between various cultures as seen in the [Globalization demo].

What ASP.NET AJAX Brings

So I was really delighted to hear that as of ASP.NET AJAX Beta 2, this information is also available on the client. Only information for current culture (on the server: System.Globalization.CultureInfo.CurrentCulture) is being propagated to the client, which makes perfect sense with - count them - 134 cultures and growing. Full documentation on this feature is not yet available, but I did a little snooping around - using the good old for/in loop mentioned in [my previous blog post], and here's what I found out. The relevant client-side object is called Sys.CultureInfo.CurrentCulture.dateTimeFormat, and its contents for my English (Canada) culture are:

AMDesignator: AM
Calendar: [object Object]
DateSeparator: /
FirstDayOfWeek: 0
CalendarWeekRule: 0
FullDateTimePattern: dddd, MMMM dd, yyyy h:mm:ss tt
LongDatePattern: dddd, MMMM dd, yyyy
LongTimePattern: h:mm:ss tt
MonthDayPattern: MMMM dd
PMDesignator: PM
RFC1123Pattern: ddd, dd MMM yyyy HH':'mm':'ss 'GMT'
ShortDatePattern: M/d/yyyy
ShortTimePattern: h:mm tt
SortableDateTimePattern: yyyy'-'MM'-'dd'T'HH':'mm':'ss
TimeSeparator: :
UniversalSortableDateTimePattern: yyyy'-'MM'-'dd HH':'mm':'ss'Z'
YearMonthPattern: MMMM, yyyy
AbbreviatedDayNames: Sun,Mon,Tue,Wed,Thu,Fri,Sat
ShortestDayNames: Su,Mo,Tu,We,Th,Fr,Sa
DayNames: Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday
AbbreviatedMonthNames: Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,
MonthNames: January,February,March,April,May,June,July,August,
IsReadOnly: false
NativeCalendarName: Gregorian Calendar
AbbreviatedMonthGenitiveNames: Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,
MonthGenitiveNames: January,February,March,April,May,June,July,

Further drilling into Sys.CultureInfo.CurrentCulture.dateTimeFormat.Calendar, we find:

MinSupportedDateTime: Thu Dec 31 19:00:00 EST 99
MaxSupportedDateTime: Fri Dec 31 18:59:59 EST 9999
AlgorithmType: 1
CalendarType: 1
Eras: 1
TwoDigitYearMax: 2029
IsReadOnly: false

As you can see, a lot of this information duplicates the settings propagated by the Calendar control. This is great, because I love to throw code away. In the near future, we will hopefully be able to rely on the client-side framework to provide date and time format information, and only propagate it ourselves when necessary.

You can use this data for your own needs with confidence. While it is not yet documented, and has the appearance of some internal code, good folks of the ASP.NET AJAX team confirm that it will be in this same form and public, supported, and documented when ASP.NET AJAX is released. Until client-side docs are available, you can rely on the server-side documentation for DateTimeFormatInfo. Client-side object is designed to duplicate it.

It feels great to see more and more of the ASP.NET framework migrate (or rather replicate itself) to the client. Soon we will all benefit from building and using a much better interweb.

Filed under: ,


marko denassus

Posted on Fri Dec 1, 2006 @ 10:03 PM

thats cool im totally going to use that

Click here to log in or create an account.