He buscado mucho, pero no pude encontrar una explicación para esto, en mi opinión, el comportamiento confuso de getTime() . La documentación dice:
getTime() siempre usa UTC para la representación del tiempo. Por ejemplo, un navegador de cliente en una zona horaria, getTime() será igual que un navegador de cliente en cualquier otra zona horaria.
De acuerdo con esta declaración, entiendo que, por ejemplo,
1. new Date (Date.UTC(2021,8,1)).getTime() // UTC Date 1.Sep.2021 00:00:00 2. new Date (2021,8,1).getTime() // Local (UTC+1) Date 1.Sep.2021 00:00:00debe entregar la misma cantidad de milisegundos. Pero los resultados que estoy obteniendo son estos:
1. 1630454400000 2. 1630447200000 // 1 hour (3600000 ms) missingPregunta A : Físicamente ha pasado la misma cantidad de tiempo desde el 1.1.1970. ¿Por qué los resultados no son iguales (también importa el horario de verano) como deberían, según los documentos?
Pregunta B : Si el comportamiento es correcto, ¿por qué falta una hora? ¿No debería haber una hora más? Lógicamente UTC+1 es una hora por delante.
Ok, descubrí qué causó la confusión. ¡Gracias por toda tu ayuda! Especialmente a Chris G, quien me indicó la dirección correcta. Esto es lo que arruinó mi cerebro ;-)
Todos los que no entendían por qué había un problema en absoluto, lo más probable es que lo estuvieran viendo desde el punto de vista de un usuario normal del navegador web. En ese escenario, si un usuario en UTC+1 abre un sitio web que llama a getTime() digamos el 1 de septiembre de 2021 a las 07:00:00, eso daría como resultado lo siguiente:
now Date ( 2021, 8, 1, 7, 0, 0 ).getTime()Ahora bien, si un segundo usuario hace lo mismo exactamente en el mismo momento en UTC+0, esto daría como resultado:
now Date ( 2021, 8, 1, 6, 0, 0 ).getTime()¡Entonces, por supuesto, estamos obteniendo los mismos resultados! Mi problema fue que asumí que llamando:
now Date ( 2021, 8, 1, 7, 0, 0 ).getTime() en diferentes zonas horarias debería dar el mismo resultado. ¡Que no es el caso! Ahora puede preguntarse por qué alguien necesitaría esto. La razón es simple. Estoy desarrollando una pequeña herramienta de Gantt en Electron y allí necesito comparar/restar fechas. Por supuesto, no necesito que lo anterior sea cierto (entregar los mismos valores), pero me encontré con este problema porque no obtenía números de milisegundos divisibles al restar fechas al convertirlas a ms con getTime() . Esperaba que según el documento, que dice que getTime() dará el mismo valor en cada zona horaria, para obtener un valor absoluto que no esté influenciado por las zonas horarias o el horario de verano, para el cálculo. Por lo tanto, esperaba que, por ejemplo:
now Date(2021,4,1,0,0,0).getTime() - now Date(2021,11,1,0,0,0).getTime()Debería dar un número de milisegundos, que debería ser perfectamente divisible por 86400000 (un día). Pero ese no fue el caso. ¡La razón es que la segunda fecha está retrasada 1 hora debido al horario de verano!
Conclusión
La declaración en el documento es verdadera cuando se mira en el mismo punto en el tiempo (por ejemplo, UTC+0 06:00 y UTC+1 07:00), pero no cuando se mira en la misma cantidad de horas (por ejemplo, UTC+0 07:00 y UTC+1 07:00). Eso fue lo que me confundió. Tal vez esta explicación ayude a otros también.