Angular.js: $ http modifica la fecha en el objeto JSON PUBLICADO (elimina la zona horaria o el desplazamiento estacional)

Creado en 25 abr. 2016  ·  3Comentarios  ·  Fuente: angular/angular.js

Creo que esto es un error.

¿Cuál es el comportamiento actual?

Actualmente tengo un objeto de fecha agradable que cierra sesión en

Viernes 29 de abril de 2016 13:33:00 GMT + 0100 (BST)

Cuando este objeto es PUBLICADO a través de $ http, se observa lo siguiente en las solicitudes de red.

2016-04-28T12: 33: 00.000Z

Por lo tanto, el objeto $ http resta una hora y elimina efectivamente la BST del horario de verano británico de la hora. Entonces esto se almacena en la base de datos sin este desplazamiento. Cuando leemos inmediatamente esta fecha, vuelve, pero ¿cómo puede saber el sistema que necesitamos volver a agregar la hora?

Así que imagine también que el usuario está en otra zona horaria ... digamos 5 horas antes, entonces el sistema restará 5 horas ... El tiempo es sensible al contexto en el que se crea. en otras palabras, no se debe eliminar la información de la zona horaria.

Veo esto en Chrome. Angular 1.4.2

También http://stackoverflow.com/questions/24356475/angular-js-date-changes-when-submitting-to-http-timezone-issue

Comentario más útil

Primero, creo que no es correcto decir que el objeto Date no tiene información de zona horaria.

Sigo pensando que es correcto decir que: grin: A Date object _ "representa un único momento en el tiempo [...] basado en un valor de tiempo que es el número de milisegundos desde el 1 de enero de 1970 UTC" _ (fuente: MDN ). Entonces, básicamente, cada instancia Date solo conoce este valor y todas las demás representaciones del mismo se inducen en función de esa información más el estado del sistema / ubicación (como el desplazamiento de la zona horaria).

#

Un objeto Date tiene métodos getTimezoneOffset y toISOString .

Estos son métodos del prototipo Date (fuente: MDN ), no de los objetos Date (también conocidos como instancias).

Más específicamente, el valor de getTimezoneOffset () depende de la configuración regional actual (configuración del sistema host). Esta es la razón por la que no hay un método setTimezoneOffset() y por qué todos los objetos Date en el mismo sistema devuelven el mismo valor para getTimezoneOffset() , por ejemplo:

const d1 = new Date('December 15, 2018 12:34:56');  // No timezone; uses the current system locale.
const d2 = new Date('December 15, 2018 12:34:56 GMT+10'); // Uses GTM+10 as timezone.

d1.getTimezoneOffset() === d2.getTimezoneOffset();  // true

Por lo tanto, la información de la zona horaria especificada en una representación de cadena de fecha pasada a Date solo se usa para analizar esa cadena y asignarla a un momento específico en el tiempo como se describe arriba. El objeto Date resultante no sabe nada sobre las zonas horarias: smiley:

El método toISOString () no imprime la información de la zona horaria como sugirió. Simplemente agrega Z al final, lo que denota UTC .

#

En segundo lugar, JSON.stringify() tampoco elimina el valor de la zona

Como se explicó anteriormente, usa toISOString() , que expresa el valor de la fecha en UTC (por lo tanto, agrega Z al final para indicar eso). No hay información de zona horaria en la cadena devuelta.

#

Así que sigo creyendo que si la API genera una fecha ISO que no tiene esos milisegundos y la interfaz de usuario está usando algún selector de fecha que solo elige una fecha y cambia la fecha, entonces Angular al devolver la fecha convirtiéndola en formato ISO, no tendrá milisegundos valor.

No tengo idea de qué tienen que ver los milisegundos con eso. Estábamos hablando de información de zona horaria.

Nuevamente, esto no tiene nada que ver con AngularJS. Así es como los objetos integrados (como Date y JSON ) interactúan entre sí.

Todos 3 comentarios

Esto no es algo específico de Angular. Es el comportamiento estándar de JSON.stringify .

Básicamente, al publicar datos, $http convierte a JSON (a través de JSON.stringify() ). En JavaScript, la representación JSON de un objeto Date es su formulario ISO-8601 (que es lo que ve en la pestaña de red).

Un objeto Date no tiene información de zona horaria de todos modos, por lo que no se elimina ninguna información. La configuración regional actual (que es totalmente independiente de la fecha representada por los objetos Date) tiene un desplazamiento de zona horaria y el navegador formatea la fecha de acuerdo con ese desplazamiento cuando console.log marca.

Cerrando ya que esto no es un problema con Angular.

@gkalpak Primero, creo que no es correcto decir que el objeto Date no tiene información de zona horaria. Cuando creamos una fecha por nueva Fecha (), la información de la zona horaria es la zona local por defecto. Un objeto Date tiene métodos getTimezoneOffset y toISOString . Cuando se llaman, estos métodos devuelven el valor de la zona, no es nada que el navegador imprima bien para nosotros, son valores reales en el objeto Date.

new Date().getTimezoneOffset()
-330

new Date().toISOString()
"2018-12-04T05:40:37.399Z"

En segundo lugar, JSON.stringify() tampoco quita el valor de la zona, lo siguiente es lo que vimos en la consola del navegador y es lo mismo, el navegador no está imprimiendo nada bueno para nosotros.

JSON.stringify({d:new Date()})
"{"d":"2018-12-04T05:42:08.973Z"}"

Así que sigo creyendo que si la API genera una fecha ISO que no tiene esos milisegundos y la interfaz de usuario está usando algún selector de fecha que solo elige una fecha y cambia la fecha, entonces Angular al devolver la fecha convirtiéndola en formato ISO, no tendrá milisegundos valor.

Primero, creo que no es correcto decir que el objeto Date no tiene información de zona horaria.

Sigo pensando que es correcto decir que: grin: A Date object _ "representa un único momento en el tiempo [...] basado en un valor de tiempo que es el número de milisegundos desde el 1 de enero de 1970 UTC" _ (fuente: MDN ). Entonces, básicamente, cada instancia Date solo conoce este valor y todas las demás representaciones del mismo se inducen en función de esa información más el estado del sistema / ubicación (como el desplazamiento de la zona horaria).

#

Un objeto Date tiene métodos getTimezoneOffset y toISOString .

Estos son métodos del prototipo Date (fuente: MDN ), no de los objetos Date (también conocidos como instancias).

Más específicamente, el valor de getTimezoneOffset () depende de la configuración regional actual (configuración del sistema host). Esta es la razón por la que no hay un método setTimezoneOffset() y por qué todos los objetos Date en el mismo sistema devuelven el mismo valor para getTimezoneOffset() , por ejemplo:

const d1 = new Date('December 15, 2018 12:34:56');  // No timezone; uses the current system locale.
const d2 = new Date('December 15, 2018 12:34:56 GMT+10'); // Uses GTM+10 as timezone.

d1.getTimezoneOffset() === d2.getTimezoneOffset();  // true

Por lo tanto, la información de la zona horaria especificada en una representación de cadena de fecha pasada a Date solo se usa para analizar esa cadena y asignarla a un momento específico en el tiempo como se describe arriba. El objeto Date resultante no sabe nada sobre las zonas horarias: smiley:

El método toISOString () no imprime la información de la zona horaria como sugirió. Simplemente agrega Z al final, lo que denota UTC .

#

En segundo lugar, JSON.stringify() tampoco elimina el valor de la zona

Como se explicó anteriormente, usa toISOString() , que expresa el valor de la fecha en UTC (por lo tanto, agrega Z al final para indicar eso). No hay información de zona horaria en la cadena devuelta.

#

Así que sigo creyendo que si la API genera una fecha ISO que no tiene esos milisegundos y la interfaz de usuario está usando algún selector de fecha que solo elige una fecha y cambia la fecha, entonces Angular al devolver la fecha convirtiéndola en formato ISO, no tendrá milisegundos valor.

No tengo idea de qué tienen que ver los milisegundos con eso. Estábamos hablando de información de zona horaria.

Nuevamente, esto no tiene nada que ver con AngularJS. Así es como los objetos integrados (como Date y JSON ) interactúan entre sí.

¿Fue útil esta página
0 / 5 - 0 calificaciones