spanish - javascript date tolocalestring timezone
Opción de zona horaria de Chrome para Date.toLocaleString() (2)
¿Es esto parte de un nuevo estándar? Tal vez enterrado en algún lugar en ECMAScript 6? ¿O es simplemente algo personalizado para Chrome?
De hecho, es parte de la nueva norma ECMA-402. El estándar es muy difícil de leer, pero hay una introducción amigable .
¿Por qué solo Google Chrome? ¿Es compatible en otro lugar? ¿Hay planes para apoyarlo en otro lugar?
MDN tiene una lista de navegadores compatibles . Según el Bug 853301 estará disponible en Firefox 25.
Revisé node.js, que usa el tiempo de ejecución de JavaScript de Chrome, pero no funciona allí. Por qué no?
Las posibles razones son muchas; no está a la altura de la base de código actual, o podría hacer que node.js sea más grande y más lento (la entrada anterior del bug buger de Mozilla indica que los datos de la zona horaria aumentaron el tamaño de descarga de Firefox en un 10% y causaron la E / S para aumentar sustancialmente durante el inicio del navegador.
¿Se puede acceder a los datos de la zona horaria de una forma distinta a las funciones que enumeré? si solo
disponible al formatear cadenas, entonces puede ser difícil realizar cualquier cálculo basado en los resultados.
Parece que no está disponible. Además, el cebador de la API Intl dice que solo UTC y la zona horaria local deben ser compatibles.
Esto está enfocado en la salida, pero ¿cómo lo usaría para la entrada? ¿Hay alguna forma de pasar la zona horaria en el constructor al objeto Fecha? Intenté lo siguiente:
La API Intl solo habla sobre el formato de fecha / hora, las intercalaciones de cadenas y el formato de números. El formato de fecha y hora no solo es compatible con el calendario gregoriano, sino también con muchos otros tipos de calendarios: lunar, lunisolar, etc.
El problema descrito en esta publicación, creado por una falla en la especificación ECMAScript 5, todavía afecta la salida, incluso cuando los datos correctos están en la TZDB. ¿Cómo es que coexisten implementaciones antiguas y nuevas? Uno pensaría que sería todo el camino viejo, o todo el camino nuevo. Por ejemplo, con la zona horaria de mi computadora configurada en hora del este de EE. UU.
nueva fecha (2004,10,7,0,0) .toLocaleString ("en-US", {timeZone: "America / New_York"})
devuelve "11/6/2004 11:00:00 PM". Debería regresar a la medianoche, ya que comencé a medianoche y mi zona horaria local coincide con la zona horaria de salida. Pero coloca la fecha de entrada provista en el punto UTC incorrecto debido al problema de ES5.
La razón de ello es que ES5 exige que la entrada a la nueva Fecha se calcule utilizando el DST y la compensación actuales, es decir, es América / Nueva York pero con la zona horaria EDT, aunque el 6 de noviembre no esté en EDT. Obviamente, como esto se especifica así, entonces no se puede cambiar. Sin embargo, dado que Chrome está utilizando la TZDB para realizar la conversión del valor UTC simple en el tiempo en UTC al tz de América / Nueva York, considera que el tiempo está en EST.
¿Puedo esperar que a medida que la IANA publique actualizaciones en la TZDB, Google empuje las actualizaciones de Chrome que contienen los cambios?
Lo creería
Recientemente he descubierto que hay una nueva extensión para JavaScript. Esto agrega varias características al objeto Date en las toLocaleString , toLocaleDateString y toLocaleTimeString . Referencia aquí .
Estoy particularmente interesado en la opción de zona timeZone , que admite zonas horarias IANA / Olson , como America/New_York o Europe/London . Esto actualmente solo es compatible con Google Chrome .
El consejo anterior fue que para trabajar en JavaScript con cualquier otra zona horaria que no sea UTC o su propia zona horaria local, uno tenía que usar una biblioteca . Pero ahora, parece que esto está empezando a incorporarse directamente en el navegador. Así que ahora puedes hacer esto:
new Date().toLocaleString("en-US", {timeZone: "America/New_York"})
// output: "7/4/2013 5:15:45 PM"
O:
new Date().toLocaleString("en-NZ", {timeZone: "Pacific/Chatham",
timeZoneName: "long"})
// output: "7/5/2013 9:59:52 AM GMT+12:45"
O:
new Date().toLocaleString("en-GB", {timeZone: "Europe/London",
timeZoneName: "short"})
// output: "4/7/2013 22:18:57 United Kingdom Time"
// (strange time zone name, but ok)
Esto es muy bueno, pero tengo algunas preguntas:
- ¿Es esto parte de un nuevo estándar? Tal vez enterrado en algún lugar en ECMAScript 6? ¿O es simplemente algo personalizado para Chrome?
- ¿Por qué solo Google Chrome? ¿Es compatible en otro lugar? ¿Hay planes para apoyarlo en otro lugar?
- Revisé node.js, que usa el tiempo de ejecución de JavaScript de Chrome, pero no funciona allí. Por qué no?
- ¿Se puede acceder a los datos de la zona horaria de una forma distinta a las funciones que enumeré? Si solo está disponible al formatear cadenas, entonces puede ser difícil realizar cualquier cálculo basado en los resultados.
Esto está enfocado en la salida, pero ¿cómo lo usaría para la entrada? ¿Hay alguna forma de pasar la zona horaria en el constructor al objeto
Date? Intenté lo siguiente:// parsing it with a date and time new Date("2013-01-01 12:34:56 America/New_York") // passing it as a named option new Date(2013,0,1,12,34,56,{timeZone:"America/New_York"})Tampoco funcionó. No pude encontrar nada en las especificaciones, así que no creo que esto exista (todavía), pero por favor dígame si estoy equivocado.
El problema descrito en esta publicación , creado por una falla en la especificación ECMAScript 5, todavía afecta la salida, incluso cuando los datos correctos están en la TZDB. ¿Cómo es que coexisten implementaciones antiguas y nuevas? Uno pensaría que sería todo el camino viejo, o todo el camino nuevo. Por ejemplo, con la zona horaria de mi computadora configurada en hora del este de EE. UU.
new Date(2004,10,7,0,0).toLocaleString("en-US",{timeZone:"America/New_York"})devuelve
"11/6/2004 11:00:00 PM". Debería regresar a la medianoche, ya que comencé a la medianoche y mi zona horaria local coincide con la zona horaria de salida. Pero coloca la fecha de entrada proporcionada en el punto UTC incorrecto debido al problema de ES5.¿Puedo esperar que a medida que la IANA publique actualizaciones en la TZDB, Google empuje las actualizaciones de Chrome que contienen los cambios?
actualizar
Hay bastante extensa redacción sobre la API here
¿Es esto parte de un nuevo estándar? Tal vez enterrado en algún lugar en ECMAScript 6? ¿O es simplemente algo personalizado para Chrome?
Sí, estos son parte de la API de internacionalización de ECMAScript . Se implementa por separado de ECMAScript, pero el requisito de implementar la API de internacionalización de ECMAScript es tener primero la implementación correcta de ECMAScript 5.1
¿Por qué solo Google Chrome? ¿Es compatible en otro lugar? ¿Hay planes para apoyarlo en otro lugar?
En los últimos años, Google Chrome ha sido el primero en implementar nuevas funciones. Mozilla es más conservador, aún por ejemplo discutiendo si implementar el atributo de download de a elemento. Ahora también está disponible en IE11 Beta y Opera . Estará disponible en Firefox 25 .
Revisé node.js, que usa el tiempo de ejecución de JavaScript de Chrome, pero no funciona allí. Por qué no?
node.js solo usa el mismo motor, que es un proyecto separado del navegador Google Chrome. El motor solo implementa Ecmascript 5.1. Esta es una extensión que node.js tendría que implementar por separado en este momento. Estará disponible en V8 en el tercer trimestre, por lo que probablemente un poco después, puede usarlo en node.js.
Esto está enfocado en la salida, pero ¿cómo lo usaría para la entrada? ¿Hay alguna forma de pasar la zona horaria en el constructor al objeto Fecha? Intenté lo siguiente:
No hay nada acerca de la introducción de fechas en la especificación. Personalmente, no puedo ver cómo esto podría ser útil, lo está haciendo mal si no está transmitiendo las marcas de hora UTC porque algo como "2013-01-01 12:34:56 America/New_York" es ambiguo durante las transiciones de DST a la hora estándar.
El problema descrito en esta publicación, creado por una falla en la especificación ECMAScript 5, todavía afecta la salida, incluso cuando los datos correctos están en la TZDB.
Este es un problema de entrada, no de salida. Nuevamente, construir una fecha con la zona horaria local que no puede influir o detectar está haciendo mal. Utilice la sobrecarga del constructor de marca de tiempo o Date.UTC .
¿Puedo esperar que a medida que la IANA publique actualizaciones en la TZDB, Google empuje las actualizaciones de Chrome que contienen los cambios?
No hay nada en la especificación, pero creo que será razonable esperar que las reglas no estén demasiado atrasadas.