Lors de la récupération des données pour une plage de dates sélectionnée, nous avons remarqué que notre calcul était légèrement erroné. Cependant, lorsque nous avons diminué la date d’un jour, les données correspondaient exactement !

Hmmm… Il se peut qu'il y ait un problème avec la façon dont la date est gérée dans notre code. Peut-être que le fuseau horaire n’est pas géré correctement – ​​et oui, j’avais raison !

Lors de la création d'applications impliquant des utilisateurs de différents fuseaux horaires, la gestion correcte des dates peut s'avérer délicate. Le stockage des dates au format UTC est une bonne pratique courante pour garantir la cohérence, mais les choses peuvent devenir compliquées lorsque les utilisateurs saisissent des dates dans leur fuseau horaire local, en particulier lors du filtrage et des requêtes.

Les développeurs ont souvent recours à l'objet JavaScript Date natif pour gérer ces conversions. Cependant, cette approche peut entraîner des incohérences entre les environnements, tels que Node.js et les consoles de navigateur comme Chrome. Dans cet article, nous découvrirons pourquoi il est crucial de gérer correctement les conversions de date et de fuseau horaire, comment Luxon peut faciliter ce processus et pourquoi s'appuyer sur l'objet Date JavaScript natif peut entraîner des incohérences.

Le problème : stockage UTC et filtrage de l'heure locale

Lorsque les dates sont stockées au format UTC, elles représentent une norme mondiale qui élimine l'ambiguïté causée par les fuseaux horaires. Cependant, les utilisateurs pensent généralement en termes de leur fuseau horaire local. Cette différence devient évidente lorsque les utilisateurs tentent de filtrer les enregistrements par date à l'aide des entrées d'heure locale.

Regardons un exemple dans lequel les entrées d'heure locale d'un utilisateur pourraient entraîner des enregistrements manqués si elles ne sont pas traitées correctement.

Exemple de scénario : un utilisateur dans le fuseau horaire GMT-7

Imaginez un utilisateur dans le fuseau horaire GMT-7 (heure avancée du Pacifique). Le 5 septembre 2024, ils créent un enregistrement à 22h00, heure locale. Voici ce qui se passe dans les coulisses :

• 5 septembre 2024, 22h00 GMT-7 est converti en 6 septembre 2024, 05h00 UTC et stocké dans la base de données en tant que tel.
• L'utilisateur perçoit cependant qu'il a créé cet enregistrement le 5 septembre.

L'inadéquation des filtres

Maintenant, supposons que l'utilisateur souhaite interroger tous les enregistrements créés le 5 septembre. Ils saisissent la date 5 septembre 2024, dans l'espoir de récupérer leur dossier. Cependant, si le système compare directement la date saisie à la date UTC stockée sans tenir compte des différences de fuseau horaire, l'utilisateur manquera l'enregistrement. Pourquoi?

• L'enregistrement a été enregistré dans la base de données le 6 septembre (UTC).
• L'utilisateur filtre pour le 5 septembre (son heure locale), mais le système compare cette information à l'heure UTC, ce qui n'aboutit à aucune correspondance.

Objet de date JavaScript : incohérences entre les environnements

L'exemple de code suivant illustre un problème courant lors de l'utilisation de l'objet JavaScript natif Date pour gérer les conversions de date et d'heure, en particulier dans différents environnements tels que Node.js et le navigateur (par exemple, la console Chrome).

Exemple de code :

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"

Dans cet exemple, l'utilisateur saisit la date « 2023-08-22T00:00:00 05:30 » (à partir d'un fuseau horaire GMT de 5h30). L'objet Date doit le convertir en début de journée en UTC, mais une fois exécuté :

• Dans Node.js, la sortie est 2023-08-21T00:00:00.000Z - Incorrect
• Dans la console Chrome, la sortie est 2023-08-21T18:30:00.000Z - Correct

Cet écart peut entraîner des résultats imprévisibles selon l'endroit où le code est exécuté. Ce comportement rend l'objet Date peu fiable pour une gestion cohérente des dates dans différents environnements.

Utiliser Luxon pour une gestion précise des dates

Pour résoudre ce problème, il est important d'utiliser une bibliothèque telle que Luxon qui fournit un comportement cohérent dans tous les environnements. Luxon vous aide à convertir l'entrée locale de l'utilisateur en début et fin de la journée dans son fuseau horaire, puis à convertir ces heures en UTC pour des requêtes de base de données précises.

Voici un exemple utilisant Luxon pour gérer cela :

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
  }
});

Pourquoi Luxon est meilleur que les objets de date JavaScript

La gestion des conversions de date et de fuseau horaire directement avec l'objet JavaScript Date natif peut entraîner des incohérences comme celle démontrée ci-dessus. Voici quelques raisons pour lesquelles Luxon est une meilleure alternative :

1. Cohérence entre les environnements : Luxon fournit un comportement cohérent, que le code soit exécuté dans Node.js ou dans le navigateur (par exemple, la console Chrome). Cela élimine les divergences résultant de l'utilisation de l'objet Date dans différents environnements.

2. Prise en charge intégrée des fuseaux horaires : Luxon facilite la conversion entre les fuseaux horaires, tandis que l'objet Date n'offre pas de prise en charge robuste pour la manipulation des fuseaux horaires.

3. Manipulation simple de la date : définir le début ou la fin d'une journée dans le fuseau horaire local de l'utilisateur et le convertir en UTC est une tâche courante dans les applications mondiales. Luxon simplifie ce processus grâce à son API intuitive, tandis que Date nécessite une gestion manuelle complexe.

Conclusion

Gérer correctement les conversions de date et de fuseau horaire est crucial pour créer des applications fiables et conviviales. Si les développeurs ne tiennent pas compte des différences de fuseau horaire lors du filtrage des enregistrements, les utilisateurs risquent de manquer des données importantes, ce qui entraîne une confusion et des erreurs potentiellement critiques.

L'utilisation de Luxon au lieu de l'objet natif JavaScript Date offre une cohérence, une meilleure gestion des fuseaux horaires et une manipulation plus facile des dates. Cela permet aux développeurs de créer une expérience transparente pour les utilisateurs sur tous les fuseaux horaires, garantissant que les requêtes fonctionnent comme prévu et qu'aucun enregistrement n'est manqué lors du filtrage.

Dans les applications mondiales, une gestion précise et fiable des dates est essentielle pour offrir une expérience de haute qualité aux utilisateurs, quel que soit leur fuseau horaire.

Réflexions finales

Avez-vous déjà rencontré une situation similaire dans laquelle la gestion de la date et du fuseau horaire provoquait des résultats inattendus dans votre application ? Comment l’avez-vous abordé ? J’aimerais connaître vos expériences, vos commentaires ou toute question ou préoccupation que vous pourriez avoir. N'hésitez pas à les partager dans la section commentaires ci-dessous. Si vous avez trouvé cet article utile, aimez-le et partagez-le avec d'autres personnes qui pourraient en bénéficier !