¿Está extendiendo Date.parse de JavaScript para permitir DD/MM/YYYY (fechas formateadas fuera de los EE. UU.)?

Question

se me ha ocurrido con esta solución para extender la función de JavaScript Date.parse para permitir fechas en formato DD/MM/AAAA (en lugar entonces el estándar estadounidense [y por defecto] MM/DD/AAAA):

(function() { 
    var fDateParse = Date.parse; 

    Date.parse = function(sDateString) { 
     var a_sLanguage = ['en','en-us'], 
      a_sMatches = null, 
      sCurrentLanguage, 
      dReturn = null, 
      i 
     ; 

      //#### Traverse the a_sLanguages (as reported by the browser) 
     for (i = 0; i < a_sLanguage.length; i++) { 
       //#### Collect the .toLowerCase'd sCurrentLanguage for this loop 
      sCurrentLanguage = (a_sLanguage[i] + '').toLowerCase(); 

       //#### If this is the first English definition 
      if (sCurrentLanguage.indexOf('en') == 0) { 
        //#### If this is a definition for a non-American based English (meaning dates are "DD MM YYYY") 
       if (sCurrentLanguage.indexOf('en-us') == -1 &&  // en-us = English (United States) + Palau, Micronesia 
        sCurrentLanguage.indexOf('en-ca') == -1 &&  // en-ca = English (Canada) 
        sCurrentLanguage.indexOf('en-ph') == -1 &&  // en-ph = English (Philippians) 
        sCurrentLanguage.indexOf('en-bz') == -1   // en-bz = English (Belize) 
       ) { 
         //#### Setup a oRegEx to locate "## ## ####" (allowing for any sort of delimiter except a '\n') then collect the a_sMatches from the passed sDateString 
        var oRegEx = new RegExp("(([0-9]{2}|[0-9]{1})[^0-9]*?([0-9]{2}|[0-9]{1})[^0-9]*?([0-9]{4}))", "i"); 
        a_sMatches = oRegEx.exec(sDateString); 
       } 

        //#### Fall from the loop (as we've found the first English definition) 
       break; 
      } 
     } 

      //#### If we were able to find a_sMatches for a non-American English "DD MM YYYY" formatted date 
     if (a_sMatches != null) { 
      var oRegEx = new RegExp(a_sMatches[0], "i"); 
       //#### .parse the sDateString via the normal Date.parse function, but replacing the "DD?MM?YYYY" with "YYYY/MM/DD" beforehand 
       //####  NOTE: a_sMatches[0]=[Default]; a_sMatches[1]=DD?MM?YYYY; a_sMatches[2]=DD; a_sMatches[3]=MM; a_sMatches[4]=YYYY 
      dReturn = fDateParse(sDateString.replace(oRegEx, a_sMatches[4] + "/" + a_sMatches[3] + "/" + a_sMatches[2])); 
     } 
      //#### Else .parse the sDateString via the normal Date.parse function 
     else { 
      dReturn = fDateParse(sDateString); 
     } 

      //#### 
     return dReturn; 
    } 
})(); 

en mi código real (dotNet), estoy recogiendo a través de la matriz a_sLanguage:

a_sLanguage = '<% Response.Write(Request.ServerVariables["HTTP_ACCEPT_LANGUAGE"]); %>'.split(','); 

Ahora, no estoy seguro de que mi acercamiento a la localización de "nosotros-en"/etc. es el más apropiado Prácticamente solo son las áreas influenciadas por los EE. UU. Y actuales/anteriores de EE. UU. (Palaos, Micronesia, Filipinas) + Belice & Canadá que usan el formato funky MM/DD/YYYY (soy estadounidense, así que puedo llamarlo funky =). Entonces uno podría argumentar con razón que si el Locale no es "en-us"/etc. primero, luego DD/MM/YYYY debería ser usado. ¿Pensamientos?

Como nota al margen ... "crecí" en PERL, pero ha sido pequeño desde que hice mucho trabajo pesado en RegEx. ¿Esa expresión se ve bien para todos?

Esto parece mucho trabajo, pero basado en mi investigación, este es sin duda la mejor manera de habilitar las fechas DD/MM/YYYY dentro de JavaScript. ¿Hay alguna manera más fácil/más agradable?

PS- Al volver a leer esta publicación justo antes del envío ... Me he dado cuenta de que se trata más de un "¿puedes revisar este código?" En lugar de una pregunta (o una respuesta incrustada en la pregunta)) Cuando comencé a escribir esto, no era mi intención terminar aquí =)

Answer 1

Yo usaría Datejs. Puede cargar directamente la versión adecuada para un código de idioma ISO dado (por ejemplo, date-en-CA.js o date-en-GB.js). Solo la capitalización es diferente.