Al recuperar datos para un rango de fechas seleccionado, notamos que nuestro cálculo estaba equivocado por cierto margen. Sin embargo, cuando reducimos la fecha en un día, ¡los datos coincidieron exactamente!

Hmmm... Puede haber un problema con la forma en que se maneja la fecha en nuestro código. Quizás la zona horaria no se esté manejando correctamente, y sí, ¡tenía razón!

Al crear aplicaciones que involucran a usuarios de diferentes zonas horarias, manejar las fechas correctamente puede ser complicado. Almacenar fechas en UTC es una práctica recomendada común para garantizar la coherencia, pero las cosas pueden complicarse cuando los usuarios ingresan fechas en su zona horaria local, especialmente durante el filtrado y las consultas.

Los desarrolladores suelen recurrir al objeto de fecha de JavaScript nativo para manejar estas conversiones. Sin embargo, este enfoque puede generar inconsistencias entre entornos, como Node.js frente a consolas de navegador como Chrome. En este artículo, exploraremos por qué es crucial manejar correctamente las conversiones de fecha y zona horaria, cómo Luxon puede facilitar este proceso y por qué confiar en el objeto Fecha nativo de JavaScript puede generar inconsistencias.

El problema: almacenamiento UTC versus filtrado de hora local

Cuando las fechas se almacenan en UTC, representan un estándar global que elimina la ambigüedad causada por las zonas horarias. Sin embargo, los usuarios normalmente piensan en términos de su zona horaria local. Esta discrepancia se hace evidente cuando los usuarios intentan filtrar registros por fecha utilizando entradas de hora local.

Veamos un ejemplo en el que las entradas de hora local de un usuario podrían provocar que se pierdan registros si no se manejan correctamente.

Escenario de ejemplo: un usuario en la zona horaria GMT-7

Imagine un usuario en la zona horaria GMT-7 (hora de verano del Pacífico). El 5 de septiembre de 2024, crean un registro a las 10:00 p.m. en su hora local. Esto es lo que sucede detrás de escena:

• 5 de septiembre de 2024, 10:00 p.m. GMT-7 se convierte a 6 de septiembre de 2024, 05:00 a.m. UTC y se almacena en la base de datos como tal.
• El usuario, sin embargo, percibe que creó este registro el 5 de septiembre.

La discrepancia del filtro

Ahora, supongamos que el usuario quiere consultar todos los registros creados el 5 de septiembre. Ingresaron la fecha 5 de septiembre de 2024, esperando recuperar su registro. Sin embargo, si el sistema compara la fecha ingresada directamente con la fecha UTC almacenada sin ajustar las diferencias de zona horaria, el usuario perderá el registro. ¿Por qué?

• El registro se guardó en la base de datos el 6 de septiembre (UTC).
• El usuario filtra para el 5 de septiembre (su hora local), pero el sistema lo compara con UTC, lo que no arroja ninguna coincidencia.

Objeto de fecha de JavaScript: inconsistencias entre entornos

El siguiente código de ejemplo demuestra un problema común al usar el objeto Date de JavaScript nativo para manejar conversiones de fecha y hora, particularmente en diferentes entornos como Node.js y el navegador (por ejemplo, la consola Chrome).

Código de ejemplo:

function convertToUtcStartOfDay(isoString) {
  // Step 1: Parse the ISO string into a Date object
  let localDate = new Date(isoString);

  // Step 2: Set the time to the start of the day (00:00:00) in local time zone
  localDate.setHours(0, 0, 0, 0);

  // Step 3: Get the UTC time using toISOString() – it converts local time to UTC
  let utcStartOfDay = localDate.toISOString();

  return utcStartOfDay; // This will be in UTC
}

// Example usage:
let frontendDate = "2023-08-22T00:00:00 05:30"; // ISO string with timezone offset
let startOfDayUtc = convertToUtcStartOfDay(frontendDate);

console.log(startOfDayUtc); // Expected output: "2023-08-21T18:30:00.000Z"

En este ejemplo, el usuario ingresa la fecha "2023-08-22T00:00:00 05:30" (de una zona horaria GMT de 5:30). El objeto Fecha debería convertirlo al inicio del día en UTC, pero cuando se ejecuta:

• En Node.js, la salida es 2023-08-21T00:00:00.000Z - Incorrecto
• En la consola de Chrome, el resultado es 2023-08-21T18:30:00.000Z - Correcto

Esta discrepancia puede causar resultados impredecibles dependiendo de dónde se ejecuta el código. Este comportamiento hace que el objeto Date no sea confiable para el manejo consistente de fechas en diferentes entornos.

Uso de Luxon para un manejo preciso de la fecha

Para resolver este problema, es importante utilizar una biblioteca como Luxon que proporcione un comportamiento consistente en todos los entornos. Luxon le ayuda a convertir la entrada local del usuario al inicio y final correctos del día en su zona horaria, y luego convertir esas horas a UTC para consultas precisas en la base de datos.

Aquí hay un ejemplo usando Luxon para manejar esto:

const { DateTime } = require('luxon');

// Example user input date in ISO string with timezone information from the frontend
const userInputDate = "2023-08-22T00:00:00 05:30"; // ISO string sent by frontend

// Step 1: Parse the ISO string to get the user's local time
const userLocalDate = DateTime.fromISO(userInputDate);

// Step 2: Convert this date to start of the day and end of the day in the user's local timezone
const startOfDayLocal = userLocalDate.startOf('day'); // start of the day in the user's timezone
const endOfDayLocal = userLocalDate.endOf('day'); // end of the day in the user's timezone

// Step 3: Convert these local start and end times to UTC
const startOfDayUtc = startOfDayLocal.toUTC().toJSDate(); // start of the day in UTC
const endOfDayUtc = endOfDayLocal.toUTC().toJSDate(); // end of the day in UTC

// Step 4: Query the database using the UTC range
db.records.find({
  createdAt: {
    $gte: startOfDayUtc,
    $lte: endOfDayUtc
  }
});

Por qué Luxon es mejor que los objetos de fecha de JavaScript

Manejar conversiones de fecha y zona horaria directamente con el objeto de fecha de JavaScript nativo puede generar inconsistencias como la demostrada anteriormente. Aquí hay algunas razones por las que Luxon es una mejor alternativa:

1. Consistencia en todos los entornos: Luxon proporciona un comportamiento consistente ya sea que el código se ejecute en Node.js o en el navegador (por ejemplo, la consola Chrome). Esto elimina las discrepancias que surgen del uso del objeto Fecha en diferentes entornos.

2. Soporte de zona horaria integrado: Luxon facilita la conversión entre zonas horarias, mientras que el objeto Fecha no ofrece soporte sólido para la manipulación de zonas horarias.

3. Manipulación simple de fecha: establecer el inicio o el final de un día en la zona horaria local del usuario y convertirlo a UTC es una tarea común en aplicaciones globales. Luxon simplifica este proceso con su API intuitiva, mientras que Date requiere un manejo manual complejo.

Conclusión

Manejar adecuadamente las conversiones de fecha y zona horaria es crucial para crear aplicaciones confiables y fáciles de usar. Si los desarrolladores no tienen en cuenta las diferencias de zona horaria al filtrar registros, los usuarios pueden perder datos importantes, lo que genera confusión y errores potencialmente críticos.

Usar Luxon en lugar del objeto de fecha de JavaScript nativo proporciona coherencia, un mejor manejo de la zona horaria y una manipulación más sencilla de las fechas. Esto permite a los desarrolladores crear una experiencia perfecta para los usuarios en todas las zonas horarias, lo que garantiza que las consultas funcionen como se espera y que no se pierda ningún registro durante el filtrado.

En aplicaciones globales, el manejo de fechas preciso y confiable es clave para brindar una experiencia de alta calidad a los usuarios, independientemente de su zona horaria.

Pensamientos finales

¿Alguna vez se ha encontrado con una situación similar en la que el manejo de fecha y zona horaria provocó resultados inesperados en su aplicación? ¿Cómo lo abordaste? Me encantaría conocer sus experiencias, comentarios o cualquier pregunta o inquietud que pueda tener. No dudes en compartirlos en la sección de comentarios a continuación. Si este artículo te resultó útil, dale Me gusta y compártelo con otras personas que puedan beneficiarse de él.