معيار RFC 9562 يسمح بتغيير الوقت داخل UUIDv7، فلا يصلح بديلًا مضمونًا لعمود created_at

يقوم UUIDv7 على فكرة أن وقت الإنشاء محفور داخل المعرّف نفسه، ولذلك يحذف مطورون كثيرون عمود created_at وفهرسه ويعتمدون على المعرّف للترتيب ولمعرفة وقت الإنشاء. لكن مقالة نشرها Robert Alexander في 19 أكتوبر 2026 عادت إلى نص المعيار، ووجدت أنه لا يقدّم هذا الضمان.

فالمعيار RFC 9562 ينص على أن التطبيقات يجوز لها تعديل الوقت الفعلي، ولا يضمن مدى قرب هذا الوقت من الساعة الحقيقية، ويسمح بتقديمه على الساعة. أي أن الوقت داخل المعرّف تقريب لا وعد.

وأجرى الكاتب تجربة قابلة للتكرار على مكتبة uuid في Python. أرجع ساعة الجهاز ساعة كاملة، فرفضت المكتبة إعادة الوقت إلى الوراء وبدأت تقدّمه بدلًا من ذلك. وكبر الفرق عن الوقت الحقيقي مع كل دفعة من 100 ألف معرّف: 3695 ثانية، ثم 3795، ثم 3894، ثم 3994. وعندما يتجاوز التوليد معرّفًا واحدًا في الملي ثانية، يكبر هذا الفرق بلا حد.

وهناك قيد ثانٍ في العداد الذي يميّز المعرّفات المولّدة في الملي ثانية نفسها. فحدّه الأدنى في المعيار 12 بت، أي أنه يفيض عند نحو 4,096 معرّفًا في الملي ثانية في العقدة الواحدة. ويحذّر توثيق Postgres بدوره من أن الوقت المستخرج من المعرّف قد لا يساوي وقت توليده.

والأثر العملي أن الترتيب بـ UUIDv7 تقريبي. فالـ pagination أو عرض “الأحدث أولًا” القائم على المعرّف قد يعيد نتائج غير مرتبة في حالتين: رجوع الساعة إلى الوراء، أو إعادة تشغيل العملية. ولأن الوقت جزء من المعرّف، فإن مشاركة أي ID، في رابط صفحة شخصية مثلًا، تكشف وقت إنشاء الحساب بدقة عالية. ويصبح الإبقاء على عمود وقت الإنشاء أرخص من نتيجة استعلام خاطئة.