أثناء استرداد البيانات لنطاق زمني محدد، لاحظنا أن حساباتنا كانت خاطئة ببعض الهامش. ومع ذلك، عندما قمنا بتقليل التاريخ بيوم واحد، تطابقت البيانات تمامًا!

هممم... قد تكون هناك مشكلة في كيفية التعامل مع التاريخ في الكود الخاص بنا. ربما لا يتم التعامل مع المنطقة الزمنية بشكل صحيح، ونعم، كنت على حق!

عند إنشاء تطبيقات تتضمن مستخدمين من مناطق زمنية مختلفة، قد يكون التعامل مع التواريخ بشكل صحيح أمرًا صعبًا. يعد تخزين التواريخ بتنسيق UTC من أفضل الممارسات الشائعة لضمان الاتساق، ولكن يمكن أن تتعقد الأمور عندما يقوم المستخدمون بإدخال التواريخ وفقًا لمنطقتهم الزمنية المحلية، خاصة أثناء التصفية والاستعلام.

غالبًا ما يلجأ المطورون إلى كائن JavaScript Date الأصلي للتعامل مع هذه التحويلات. ومع ذلك، يمكن أن يؤدي هذا الأسلوب إلى حالات عدم اتساق عبر البيئات، مثل Node.js مقابل وحدات تحكم المتصفح مثل Chrome. في هذه المقالة، سنستكشف سبب أهمية التعامل مع تحويلات التاريخ والمنطقة الزمنية بشكل صحيح، وكيف يمكن لـ Luxon أن تجعل هذه العملية أسهل، ولماذا يمكن أن يؤدي الاعتماد على كائن JavaScript Date الأصلي إلى حالات عدم اتساق.

المشكلة: تخزين التوقيت العالمي المتفق عليه (UTC) مقابل تصفية التوقيت المحلي

عندما يتم تخزين التواريخ بالتوقيت العالمي المنسق، فإنها تمثل معيارًا عالميًا يزيل الغموض الذي تسببه المناطق الزمنية. ومع ذلك، يفكر المستخدمون عادةً فيما يتعلق بمنطقتهم الزمنية التوقيت المحلي. يصبح هذا التناقض واضحًا عندما يحاول المستخدمون تصفية السجلات حسب التاريخ باستخدام مدخلات التوقيت المحلي.

دعونا نلقي نظرة على مثال حيث يمكن أن تؤدي مدخلات التوقيت المحلي للمستخدم إلى فقدان السجلات إذا لم يتم التعامل معها بشكل صحيح.

سيناريو المثال: مستخدم في المنطقة الزمنية GMT-7

تخيل مستخدمًا في المنطقة الزمنية توقيت جرينتش-7 (توقيت المحيط الهادئ الصيفي). في الخامس من سبتمبر 2024، قاموا بإنشاء رقم قياسي في الساعة 10:00 مساءً بالتوقيت المحلي. إليك ما يحدث خلف الكواليس:

• يتم تحويل يوم 5 سبتمبر 2024، الساعة 10:00 مساءً بتوقيت GMT-7 إلى يوم 6 سبتمبر 2024، الساعة 05:00 صباحًا بالتوقيت العالمي المنسق ويتم تخزينه في قاعدة البيانات على هذا النحو.
• ومع ذلك، يدرك المستخدم أنه أنشأ هذا السجل في الخامس من سبتمبر.

عدم تطابق عامل التصفية

الآن، لنفترض أن المستخدم يريد الاستعلام عن جميع السجلات التي تم إنشاؤها في الخامس من سبتمبر. يقومون بإدخال التاريخ 5 سبتمبر 2024، متوقعين استرداد سجلهم. ومع ذلك، إذا قام النظام بمقارنة تاريخ الإدخال مباشرة بتاريخ UTC المخزن دون تعديل اختلافات المنطقة الزمنية، فإن المستخدم سوف يفوت السجل. لماذا؟

• تم حفظ السجل في قاعدة البيانات باسم 6 سبتمبر (التوقيت العالمي المنسق).
• يقوم المستخدم بتصفية الخامس من سبتمبر (التوقيت المحلي)، لكن النظام يقارن ذلك بالتوقيت العالمي المنسق (UTC)، مما يؤدي إلى عدم وجود تطابق.

كائن تاريخ جافا سكريبت: التناقضات عبر البيئات

يوضح رمز المثال التالي مشكلة شائعة عند استخدام كائن JavaScript Date الأصلي للتعامل مع تحويلات التاريخ والوقت، خاصة عبر بيئات مختلفة مثل Node.js والمتصفح (على سبيل المثال، وحدة تحكم Chrome).

رمز المثال:

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"

في هذا المثال، يقوم المستخدم بإدخال التاريخ "2023-08-22T00:00:00 05:30" (من المنطقة الزمنية GMT 5:30). يجب أن يقوم كائن التاريخ بتحويله إلى بداية اليوم بالتوقيت العالمي المنسق (UTC)، ولكن عند تنفيذه:

• في Node.js، يكون الإخراج 2023-08-21T00:00:00.000Z - خطأ
• في وحدة تحكم Chrome، يكون الإخراج 2023-08-21T18:30:00.000Z - صحيح

يمكن أن يؤدي هذا التناقض إلى نتائج غير متوقعة اعتمادًا على مكان تنفيذ التعليمات البرمجية. هذا السلوك يجعل كائن التاريخ غير موثوق به لمعالجة التاريخ بشكل متسق عبر بيئات مختلفة.

استخدام Luxon للتعامل الدقيق مع التاريخ

لحل هذه المشكلة، من المهم استخدام مكتبة مثل Luxon التي توفر سلوكًا متسقًا عبر البيئات. يساعدك Luxon على تحويل الإدخال المحلي للمستخدم إلى بداية ونهاية اليوم في منطقته الزمنية، ثم تحويل تلك الأوقات إلى UTC لاستعلامات قاعدة البيانات الدقيقة.

إليك مثال باستخدام Luxon للتعامل مع هذا:

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

لماذا يعتبر Luxon أفضل من كائنات التاريخ في JavaScript

يمكن أن يؤدي التعامل مع تحويلات التاريخ والمنطقة الزمنية مباشرةً باستخدام كائن JavaScript Date الأصلي إلى تناقضات مثل تلك الموضحة أعلاه. فيما يلي بعض الأسباب التي تجعل لوكسون بديلاً أفضل:

1. الاتساق عبر البيئات : توفر Luxon سلوكًا متسقًا سواء كان الكود يعمل في Node.js أو المتصفح (على سبيل المثال، وحدة تحكم Chrome). يؤدي هذا إلى إزالة التناقضات التي تنشأ عن استخدام كائن التاريخ في بيئات مختلفة.

2. دعم المنطقة الزمنية المدمج : يجعل Luxon من السهل التحويل بين المناطق الزمنية، في حين أن كائن التاريخ لا يقدم دعمًا قويًا لمعالجة المنطقة الزمنية.

3. معالجة بسيطة للتاريخ : يعد تعيين بداية أو نهاية اليوم في المنطقة الزمنية المحلية للمستخدم وتحويلها إلى UTC مهمة شائعة في التطبيقات العالمية. تعمل Luxon على تبسيط هذه العملية من خلال واجهة برمجة التطبيقات البديهية الخاصة بها، بينما يتطلب التاريخ معالجة يدوية معقدة.

خاتمة

يعد التعامل مع تحويلات التاريخ والمنطقة الزمنية بشكل صحيح أمرًا بالغ الأهمية لإنشاء تطبيقات موثوقة وسهلة الاستخدام. إذا فشل المطورون في مراعاة اختلافات المنطقة الزمنية عند تصفية السجلات، فقد يفقد المستخدمون بيانات مهمة - مما يؤدي إلى حدوث ارتباك وربما أخطاء فادحة.

استخدام Luxon بدلاً من كائن تاريخ JavaScript الأصلي يوفر الاتساق ومعالجة أفضل للمنطقة الزمنية ومعالجة أسهل للتواريخ. يتيح ذلك للمطورين إنشاء تجربة سلسة للمستخدمين عبر المناطق الزمنية، مما يضمن عمل الاستعلامات كما هو متوقع، وعدم فقدان أي سجلات أثناء التصفية.

في التطبيقات العالمية، تعد المعالجة الدقيقة والموثوقة للتاريخ أمرًا أساسيًا لتقديم تجربة عالية الجودة للمستخدمين، بغض النظر عن منطقتهم الزمنية.

الأفكار النهائية

هل سبق لك أن واجهت موقفًا مشابهًا حيث تسببت معالجة التاريخ والمنطقة الزمنية في نتائج غير متوقعة في تطبيقك؟ كيف تناولت الأمر؟ أود أن أسمع عن تجاربك أو تعليقاتك أو أي أسئلة أو مخاوف قد تكون لديك. لا تتردد في مشاركتها في قسم التعليقات أدناه. إذا وجدت هذه المقالة مفيدة، يرجى الإعجاب بها ومشاركتها مع الآخرين الذين قد يستفيدون منها!