yyyy moment examples javascript timezone datetimepicker momentjs timezoneoffset

moment - ¿Por qué JavaScript Date.getTimezoneOffset() considera "-05: 00" como un desplazamiento positivo?



moment to timestamp (2)

Noté que para nosotros en la zona horaria del Este ("America / New_York") con el desplazamiento de la zona horaria de "-05: 00" Date.getTimezoneOffset () devuelve un número positivo de 300. Esperaría que el desplazamiento en minutos fuera negativo en áreas para al oeste de Utc, y para ser positivo en áreas al este de Utc, pero aparentemente está "volteado". ¿Cuál es el razonamiento detrás de esa decisión?

http://momentjs.com/ sigue la misma regla y regresa ...

moment.parseZone("01/13/2014 3:38:00 PM +01:00").zone() // == -60 moment.parseZone("01/13/2014 3:38:00 PM -01:00").zone() // == 60

Al mismo tiempo, DateTimePicker http://trentrichardson.com/examples/timepicker/ no cambia los números al establecer su parámetro inicial de "zona horaria". ¿Esta mal?


Elaborando un poco sobre la respuesta perfectamente aceptable de Raina77ow ...

Primero, comprenda que los principales estándares involucrados aquí son ISO 8601 y RFC 822 (y sus parientes 733 , 1123 y 2822 ), que fueron todos (en parte) derivados de ANSI X3.51-1975.

Todos estos estándares usan la convención de que los valores positivos están al Este de UTC / GMT y los valores negativos están al Oeste de UTC / GMT.

El único estándar del que tengo constancia es que ha invertido POSIX (consulte la sección POSIX de la wiki de etiqueta de zona horaria y este artículo ), y explica por qué la compatibilidad con versiones anteriores de las zonas horarias Olson como "Etc / GMT + 5" tiene su signo invertido (Por supuesto, es posible que haya otros usos y simplemente no los conozco).

Créalo o no, JavaScript lo hace AMBAS maneras. Cuando se utiliza como cadena (en la sintaxis RFC 822 o ISO 8601) utiliza horas y minutos con desplazamientos positivos al este de UTC. Pero al llamar al método getTimezoneOffset() en el objeto Date , devuelve minutos enteros que son positivos al oeste de UTC.

Uno solo puede especular por qué existe esta inconsistencia. La especificación de ECMAScript está llena de problemas como este. Quizás sea porque cuando ve un desplazamiento en una cadena ISO 8601 o RFC 822, ese desplazamiento ya se ha aplicado. Pero cuando llama a getTimezoneOffset() , es el desplazamiento el que se debe aplicar para devolverlo a UTC.

Por ejemplo, 2014-01-01T00:00:00-05:00 es igual a 2014-01-01T05:00:00Z . Entonces getTimezoneOffset() devolvería 300 . Si agrega 300 minutos al valor original, regresa a UTC.

Son dos caras de la misma moneda. ¿Ver?

Con respecto a si ese control específico es incorrecto o no, no estoy seguro. No estoy familiarizado con ese control en particular. Veo en sus documentos el ejemplo de que -0400 es igual a -240, lo que se podría esperar que se revierte, pero de nuevo es un poco extraño tener un valor como -240 presentado a un usuario. Realmente, no deberías exponer las compensaciones a un usuario de ninguna manera (en mi humilde opinión). Es mucho mejor utilizar un control de selector de zona horaria, como este o este .


Porque así es como está definido. Citando el documento ( MDN ):

El desplazamiento de la zona horaria es la diferencia, en minutos, entre el UTC y la hora local. Tenga en cuenta que esto significa que la compensación es positiva si la zona horaria local está detrás de UTC y negativa si está adelante .