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.