هل يتضمن هيكل Windows FILETIME الثواني الكبيسة؟

StackOverflow https://stackoverflow.com/questions/130573

سؤال

ال FILETIME بناء يتم حسابها اعتبارًا من 1 يناير 1601 (بداية ذلك اليوم على الأرجح) وفقًا لوثائق Microsoft، ولكن هل يشمل ذلك الثواني الكبيسة؟

هل كانت مفيدة؟

المحلول

السؤال لا ينبغي أن يكون إذا FILETIME يتضمن ثواني كبيسة.

ينبغي أن يكون:

هل الأشخاص والوظائف والمكتبات الذين يفسرون أ FILETIME (أي. FileTimeToSystemTime) تضمين الثواني الكبيسة عند حساب المدة؟

الجواب البسيط هو "لا". FileTimeToSystemTime إرجاع ثانية كما 0..59.

الجواب الأبسط هو:"بالطبع لا، كيف يمكن ذلك؟".

لا يعرف جهازي الذي يعمل بنظام التشغيل Windows 2000 أنه تمت إضافة ثانيتين كبيستين خلال العقد الذي مضى منذ إصداره.أي تفسير يقدمه أ FILETIME خطأ.

وأخيراً، بدلاً من الاعتماد على المنطق، يمكننا أن نحدد بالملاحظة التجريبية المباشرة إجابة سؤال الملصقات:

var
    systemTime: TSystemTime;
    fileTime: TFileTime;
begin
    //Construct a system-time for the 12/31/2008 11:59:59 pm
    ZeroMemory(@systemTime, SizeOf(systemTime));
    systemtime.wYear := 2008;
    systemTime.wMonth := 12;
    systemTime.wDay := 31;
    systemTime.wHour := 23;
    systemtime.wMinute := 59;
    systemtime.wSecond := 59;

    //Convert it to a file time
    SystemTimeToFileTime(systemTime, {var}fileTime);

    //There was a leap second 12/31/2008 11:59:60 pm
    //Add one second to our filetime to reach the leap second
    filetime.dwLowDateTime := fileTime.dwLowDateTime+10000000; //10,000,000 * 100ns = 1s

    //Convert the filetime, sitting on a leap second, to a displayable system time
    FileTimeToSystemTime(fileTime, {var}systemTime);

    //And now print the system time
    ShowMessage(DateTimeToStr(SystemTimeToDateTime(systemTime)));

إضافة ثانية واحدة ل 

12/31/2008 11:59:59pm

يعطي

1/1/2009 12:00:00am

بدلا من

1/1/2009 11:59:60pm

Q.E.D.

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

نصائح أخرى

هنابعض المعلومات الإضافية حول سبب اختيار هذا التاريخ المحدد.

يسجل هيكل FileTime وقتًا في شكل 100 فترات من النانو ثانية منذ 1 يناير 1601.لماذا تم اختيار ذلك التاريخ؟

يعمل التقويم الغريغوري في دورة مدته 400 عام ، و 1601 هي السنة الأولى من الدورة التي كانت نشطة في الوقت الذي تم فيه تصميم Windows NT.وبعبارة أخرى ، تم اختياره لجعل الرياضيات تخرج بشكل جيد.

لدي بالفعل البريد الإلكتروني من ديف كاتلر يؤكد هذا.

لا يمكن أن يكون هناك إجابة واحدة على هذا السؤال دون اتخاذ قرار أولي:ما هو حساب Windows FILETIME فعليًا؟تقول مستندات Microsoft إنها تحسب 100 فاصل زمني بالنانو ثانية منذ 1601 بالتوقيت العالمي، لكن هذا يمثل مشكلة.

لم يكن هناك أي شكل من أشكال الوقت المنسق دوليًا قبل عام 1960.لم يرد اسم UTC نفسه في أي من المؤلفات قبل عام 1964.لم يكن اسم UTC كتسمية رسمية موجودًا حتى عام 1970.لكن الأمر يزداد سوءا.لم يتم إنشاء مرصد غرينتش الملكي حتى عام 1676، لذا فإن محاولة تفسير FILETIME على أنها GMT ليس لها معنى واضح، وفي ذلك الوقت فقط بدأت ساعات البندول ذات ميزان الساعة الدقيق في إعطاء دقة قدرها ثانية واحدة.

إذا تم تفسير FILETIME على أنه متوسط ​​الثواني الشمسية، فإن عدد الثواني الكبيسة منذ 1601 هو صفر، لأن UT لا يحتوي على ثواني كبيسة.إذا تم تفسير FILETIME كما لو كان هناك كرونومتر ذري، فإن عدد الثواني الكبيسة منذ عام 1601 هو حوالي -60 (أي سالب 60 ثانية كبيسة).

هذا تاريخ قديم، فماذا عن عصر الكرونومتر الذري؟وهو ليس أفضل لأن الحكومات الوطنية لم تميز بين متوسط ​​الثواني الشمسية وثواني النظام الدولي.ظل قطاع الاتصالات الراديوية (ITU-R) طوال عقد من الزمن يناقش التخلي عن الثواني الكبيسة، إلا أن ذلك لم يتوصل إلى إجماع دولي.ويمكن رؤية جزء من السبب في ذلك فيجافا سكريبت على هذه الصفحة (انظر أيضًا رابط delta-T الموجود في تلك الصفحة للاطلاع على قطع من التاريخ القديم).ونظرًا لأن الحكومات الوطنية لم تقم بتمييز واضح، فإن أي محاولة لتحديد عدد الثواني منذ عام 1972 قد تكون غير صالحة وفقًا لقوانين بعض الولايات القضائية.ويدرك مندوبو قطاع الاتصالات الراديوية هذا التعقيد، كما يدركه أعضاء لجنة POSIX.وإلى أن يتم حل القضايا الدبلوماسية، وإلى أن تقوم الحكومات الوطنية والمعايير الدولية بالتمييز والاختيار بشكل واضح بين متوسط ​​الثواني الشمسية وثانية النظام الدولي، سيكون هناك أمل ضئيل في أن تحذو معايير الكمبيوتر حذوها.

تتم إضافة الثواني الكبيسة بشكل غير متوقع بواسطة IERS.تمت إضافة 23 ثانية منذ عام 1972، عندما تم تحديد التوقيت العالمي المنسق (UTC) والثواني الكبيسة.وتقول ويكيبيديا "نظرًا لأن معدل دوران الأرض لا يمكن التنبؤ به على المدى الطويل، فمن غير الممكن التنبؤ بالحاجة إليها قبل أكثر من ستة أشهر".

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

بالإضافة إلى ذلك، فإن الانحراف المنتظم للساعة، للساعة الإلكترونية البسيطة في جهاز الكمبيوتر الخاص بك مقارنة بالتوقيت العالمي المنسق (UTC)، أكبر بكثير من التعويض المطلوب للثواني الكبيسة.إذا كنت بحاجة إلى هذا النوع من الدقة للتعويض عن الثواني الكبيسة، فيجب ألا تستخدم ساعة الكمبيوتر الشخصي غير الدقيقة للغاية.

كانت الإجابة على هذا السؤال هي لا، ولكنها تغيرت إلى: نعم، نوعًا ما، في بعض الأحيان...

لكل مقالة مدونة فريق Windows Networking:

بدءًا من Server 2019 وWindows 10 October [2018]، ستأخذ واجهات برمجة التطبيقات (APIs) الخاصة بوقت التحديث الآن في الاعتبار جميع الثواني الكبيسة التي يعرفها نظام التشغيل عندما يقوم بترجمة FILETIME إلى SystemTime.

نظرًا لعدم إصدار أي ثوان كبيسة منذ وقت إضافة هذه الميزة، فإن نظام التشغيل لا يزال غير مدرك لأي ثواني كبيسة.ومع ذلك، عندما تشق الثانية الكبيسة الرسمية التالية طريقها إلى العالم، فإن أجهزة الكمبيوتر التي تعمل بنظام التشغيل Windows والتي تم تمكين هذه الميزة الجديدة ستتتبعها، وبالتالي FILETIME سيتم تعويض القيم بعدد الثواني الكبيسة على الكمبيوتر في وقت تفسيرها.

يستمر منشور المدونة في وصف:

لم يتم إجراء أي تغيير على FILETIME.ولا يزال يمثل عدد الفواصل الزمنية 100 ns منذ بداية العصر.ما تغير هو تفسير هذا الرقم عند تحويله إلى SYSTEMTIME والعودة.فيما يلي قائمة بواجهات برمجة التطبيقات المتأثرة:

  • GetSystemTime
  • GetLocalTime
  • FileTimeToSystemTime
  • FileTimeToLocalTime
  • SystemTimeToFileTime
  • SetSystemTime
  • SetLocalTime

قبل هذا الإصدار، كان لدى SYSTEMTIME قيم صالحة لـ wSecond بين 0 و59.تم الآن تحديث SYSTEMTIME للسماح بقيمة 60، بشرط أن تمثل السنة والشهر واليوم اليوم الذي تكون فيه الثانية الكبيسة صالحة.

...

من أجل الحصول على 60 ثانية في بنية SYSTEMTIME، يجب على العملية الاشتراك بشكل صريح.

لاحظ أن الاشتراك ينطبق على السلوك ضمن الوظائف المدرجة في كيفية FILETIME تم تعيينه إلى أ SYSTEMTIME.بغض النظر عما إذا قمت بالاشتراك أم لا، فسيظل نظام التشغيل يعوض FILETIME القيم وفقًا للثواني الكبيسة التي يعرفها.

وفيما يتعلق بالتوافق جاء في المقال ما يلي:

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

ويوفر أيضًا روابط لـ وظيفة سابقة والذي يوضح كيفية تعطيل الميزة بأكملها، كما يلي:

...يمكنك العودة إلى سلوك نظام التشغيل السابق وتعطيل الثواني الكبيسة في جميع المجالات عن طريق إضافة مفتاح التسجيل التالي:

  • HKLM:\SYSTEM\CurrentControlSet\Control\LeapSecondInformation
  • يكتب:"REG_DWORD"
  • اسم:ممكّن
  • قيمة: 0 تعطيل الإعداد على مستوى النظام
  • قيمة: 1 تمكين الإعداد على مستوى النظام

بعد ذلك، أعد تشغيل النظام الخاص بك.

ملخص قاسٍ جداً:

UTC = (التوقيت الذري) + (الثواني الكبيسة) ~~ (متوسط ​​التوقيت الشمسي)

تقول وثائق MS، على وجه التحديد، "UTC"، وبالتالي يجب أن تتضمن الثواني الكبيسة.كما هو الحال دائمًا مع مرض التصلب العصبي المتعدد، قد يختلف عدد الأميال المقطوعة.

وفقا لهذا تعليق النوافذ غير مدركة تمامًا للثواني الكبيسة.إذا أضفت 24 * 60 * 60 ثانية إلى FILETIME الذي يمثل 1:39:45 اليوم، فستحصل على FILETIME الذي يمثل 1:39:45 غدًا، مهما حدث.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top