0
votes

How to handle dates with different cultures i.e how can i use common javascript code to handle dates for all cultures. For example -

Globalize.culture( "en" );
Globalize.parseDate( "1/2/2003" ); // Thu Jan 02 2003
Globalize.culture( "fr" );
Globalize.parseDate( "1/2/2003" ); // Sat Feb 01 2003

In the above code how i can make generic code instead of changing date format for different cultures.

Thanks in advance

3

3 Answers

1
votes

You cannot. There is no date notation that is shared by all cultures. The example of 1/2/2003 is particularly illustrative: you cannot know what it means, unless you have reliable information about the cultural conventions that person who produced it was using. In fact, you would need to distinguish between en-US (US English) and en-GB (British English).

The Globalize.js library is meant to deal with this variation, not to remove it.

It is possible to allow different date notations e.g. as follows (code excerpt from my book [Going Global with JavaScript and Globalize.js][1]):
function read(dateInput) { 
  var languages = ['en', 'fi', 'sv', 'ru']; 
  var formats = ['d', 'D']; 
  var date; 
  for(var langNr in languages) { 
    for(var fmtNr in formats) { 
      date = Globalize.parseDate(dateInput,formats[fmtNr],languages[langNr]); 
      if(date != null) { 
        return date; 
      } 
    } 
  } 
  return null; 
}

This would allow short and long date notations as used in (US) English, Finnish, Swedish, and Russian, so it would be fairly liberal and suitable for a situation where users are expected to use one of those languages.

But the more locales you add, the more ambiguities arise. If a notation like 1/2/2003 is allowed in different locales but has several meanings in them, then your loop structure would define which meaning is applied. This in turn could mean that input would be taken in a meaning that is differs from the user’s intent. It might be better to avoid all-numeric date notations for this reason. Formats that require month name are much safer.

Formats such as 2003-02-01 are unambiguous in principle, but only in principle, and they look unnatural to most people. You can read such formats in Globalize.js, though; you just need to specify the format explicitly.

0
votes

You mean internationalisation. There are standards, such as ISO8601, that specify unambiguous formats such as 2012-02-01 for 1 February, 2012.

I don't think date formats are related to "culture", more to nationality. The vast majority of English speakers in the world use a format of day/month/year, that is related to the country in which they live rather than the any culture they may follow or support.

There are other unambiguous formats, such as always using the month name rather than number, e.g. 01-Feb-2012 or 1 February 2012. The same works for calendars other than Gregorian.

0
votes

To be honest, your question is not very clear. From the context, I deduce you want to let users enter the date in their native format and use Globalize to somehow automatically "detect" what the format will be and apply appropriate parsing method.

If that is what you are after, it can't be done. You already know about differences in formatting for various countries. To make matters worse, there could be long or short format used (unfortunately Globalize does not support the concept of default format available in .Net by calling DateTime's ToString("g")). That means, that you may have things like "2012-10-31", "31.10.12" and "31 października 2012", which are all (more or less) valid Polish date formats.

I hope now you realize that allowing free-form input is not a good idea. So what to do instead? The answer is to use jQuery UI's Datepicker. It could be fairly easy localized, all you have to do is to add valid regional script:

$( "#datepicker" ).datepicker( $.datepicker.regional[ "fr" ] );

Then, to get JavaScript's Date object you call Datepicker's getDate() method:

var currentDate = $( ".selector" ).datepicker( "getDate" );

That's it. BTW. Datepicker allows for converting dates entered by end user (if you attach it to the text field). But of course it will be the format specified by regional script...