سؤال كيف يمكن "إنشاء" ملف في عام 1641؟


قبل بضع سنوات ، تعثرت على هذا الملف على ملفاتنا.

Screenshot of a file properties dialog in Microsoft Windows

وأتساءل كيف يمكن لملف يقول أنه تم إنشاؤه في 1641؟ بقدر ما أعرف ، يتم تعريف الوقت على جهاز الكمبيوتر عن طريق عدد الثواني منذ يناير 1st ، 1970. إذا كان هذا الفشل يخرج ، يمكنك الحصول على 31 ديسمبر 1969 (المؤشر على الارجح يقول -1) ولكن أنا متعكز في هذا على ما يبدو تاريخ عشوائي ، يسبق حتى تأسيس الولايات المتحدة الأمريكية.

فكيف يمكن تأريخ الملف في ١٦٤١؟

ملاحظة: التواريخ باللغة الفرنسية. Février هو فبراير.


74
2018-03-27 14:33


الأصل


"بقدر ما أعرف ، يتم تحديد الوقت على جهاز الكمبيوتر عن طريق عدد الثواني منذ الأول من يناير عام 1970." - حتى بالنسبة للأنظمة التي توجد فيها ، يتم تمثيل التواريخ قبل عام 1970 بسهولة عن طريق جعل هذا الرقم (المعروف باسم يونيكس الطابع الزمني) نفي. على سبيل المثال ، يتوافق unix time -1000000000 مع 1938-04-24 22:33:20. - marcelm
marcelm نعم ، ولكن الحد الأدنى للتاريخ المحتمل في عام 1901 بسبب النطاق المحدود للأعداد الصحيحة 32 بت. - slhck
slhck: أعتقد أن marcelm كان يفترض طابعًا زمنيًا من 64 بتًا ، لأن ذلك هو ما تستخدمه حاليًا أنظمة ملفات Unix / Linux الحالية و kernels و space-space. شاهد clock_gettime(2) صفحة رجل لتعريف struct timespecوهو ما statاستخدام مكالمات النظام الأخرى لتمرير الطوابع الزمنية بين مساحة المستخدم و kernel. انها بنية مع time_t في ثوان ، و long tv_nsec نانو ثانية. في أنظمة 64 بت ، كلاهما 64 بت ، وبالتالي يكون الطابع الزمني بالكامل 128 بت (16 بايت). (آسف على الكثير من التفاصيل ، حصلت على تحمل بعيدا.) - Peter Cordes
لديك إجابة جيدة لكيفية ختم التاريخ في القرن السابع عشر بالملف ، والآن حان الوقت للتفكير في كيفية حدوث ذلك. كنت أنظر إلى محتويات ملف wp عن كثب لمعرفة ما قد تمت إضافته ، لأن ذلك قد يلقي الضوء على كيفية حدوثه. كنت أنظر إلى المكونات الإضافية المثبتة والتحقق من صحة أي شيء مشكوك فيه. أفكر في شيء تعديل هذا الملف وحاولوا يدويا ختم التواريخ المعدلة / التي تم إنشاؤها للاختباء أنه تم تعديل الملف ولكن تحديد وقت unix بدلاً من وقت Windows. - Thomas Carlisle
كان الملك لويس الثالث عشر قد برهن على التزام الخط الملكي بـ PHP؟ - Jesse Slicer


الأجوبة:


لماذا تاريخ من 1600s ممكن؟

لا يقوم Windows بتخزين الطوابع الزمنية لتعديل الملف مثل أنظمة يونكس. وفقا ل مركز تطوير ويندوز (التأكيد على الألغام):

وقت الملف هو قيمة 64 بت التي تمثل عدد 100 nanosecond الفترات التي انقضت منذ 12:00 صباحًا. 1 يناير 1601 التوقيت العالمي المنسق (UTC). يسجل النظام أوقات الملفات عندما تقوم التطبيقات بإنشاء ، والوصول ، والكتابة إلى الملفات.

لذلك ، من خلال تعيين قيمة خاطئة هنا ، يمكنك بسهولة الحصول على تواريخ من القرن السابع عشر.

بطبيعة الحال ، هناك سؤال مهم آخر هو: كيف تم وضع هذه القيمة؟ ما هو التاريخ الفعلي؟ أعتقد أنك لن تكون قادرًا على اكتشاف ذلك ، لأن ذلك ربما كان مجرد خطأ حسابي في برنامج تشغيل نظام الملفات. يفترض إجابة أخرى أن التاريخ هو في الواقع طابع زمني لـ UNIX يتم تفسيره على أنه طابع زمني Windows ، ولكن يتم حسابه فعليًا على فترات زمنية مختلفة (ثانية مقابل nanoseconds).

كيف يرتبط هذا بمشكلة عام 2038؟

يعني استخدام نوع بيانات 64 بت أن Windows (بشكل عام) لا يتأثر بـ عام 2038 مشكلة أن أنظمة Unix التقليدية لها ، منذ أن استخدمت Unix مبدئيًا عددًا صحيحًا 32 بت ، والذي يفيض في وقت أقرب من عدد صحيح 64 بت الذي يحتوي عليه Windows. (هذا على الرغم من أن Unix يعمل في ثوانٍ و Windows يعمل على micro / nanoseconds.)

شبابيك لا يزال يتأثر عند استخدام برامج 32 بت التي تم ترجمتها مع الإصدارات القديمة من Visual Studio ، بالطبع.

أحدث أنظمة التشغيل يونيكس قد توسعت بالفعل نوع البيانات إلى 64 بت ، وبالتالي تجنب المشكلة. (في الواقع ، حيث تعمل الطوابع الزمنية لـ Unix في ثوانٍ ، سيكون تاريخ التفاف الملف الجديد 292 مليار سنة من الآن).

ما هو الحد الأقصى للتاريخ الذي يمكن ضبطه؟

للأشياء الفضولية - إليك طريقة حساب ذلك:

  • ال عدد القيم الممكنة في عدد صحيح 64 بت هي 263 - 1 = 9223372036854775807.
  • يمثل كل علامة 100 نانوثانية ، أي 0.1 ميكرو ثانية أو 0.0000001 ثانية.
  • أقصى نطاق زمني سيكون 9223372036854775807 ⨉ 0.0000001 s، حتى مئات المليارات من الثواني.
  • ساعة واحدة لديها 3600 ثانية ، يوم واحد لديه 86400 ثانية ، وسنة واحدة لديها 365 يوما ، لذلك هناك 86400 ⨉ 365 ثانية = 31536000 ثانية في سنة. هذا ، بالطبع ، هو فقط متوسط ​​، يتجاهل سنوات الكيب ، أو الثواني الكبيسة ، أو أي تغييرات في التقويم ، والتي قد تمليها أنظمة ما بعد الكينونة في المستقبل على الأرض المتبقية.
  • 9223372036854775807 ⨉ 0.0000001 s / 31536000 s ≈ 29247 سنة
  • @corsiKa يوضح كيف يمكننا طرح السنوات الكبيسة: 29247/365/4 ≈ 20
  • لذا فإن الحد الأقصى للسنة هو 1601 + 29247 - 20 = 30828.

بعض الناس لديهم حاول في الواقع لضبط هذا وجاءت في نفس العام.


106
2018-03-27 14:41



للسجل ، حل Unix (أو على الأقل Linux) بالفعل مشكلة 2038 لـ kernel / filesystems على معماريات 64-bit حيث time_t هو نوع 64 بت ، لذا نأمل استخدام التطبيقات time_t بدلاً من نوع صحيح لا يزال 32 بت ، وسيقوم بإزالة الطوابع الزمنية ... على أي حال ، في حالة ما إذا كان أي شخص لديه فضول حول حالة المشكلة ، فإنه يتم حلها في الغالب باستثناء الإصدار 32 بت. IDK إذا كانت ARM 32 بت ستظل ذات صلة في 2038 ، لكن هذا سيجبر تغيير ABI على الأقل. 32-bit x86 اختفت إلى حد كبير في عالم يونكس. انها فقط ويندوز حيث لا يزال رمز 32 بت شائعة. - Peter Cordes
التعليقات ليست للمناقشة الموسعة. كانت هذه المحادثة انتقل إلى الدردشة. - Journeyman Geek♦
وقت VMS هو "قيمة 64 بت التي تمثل عدد الفترات الزمنية 100 nanosecond التي انقضت منذ ذلك الحين"17-نوفمبر -1885. :) - RonJohn
السنة 30k ... منخفضة بشكل مدهش - John Dvorak
@البطة دونالد blogs.msdn.microsoft.com/oldnewthing/20090306-00/؟p=18913 وما زال حوالي 1600 شخص يستخدمون تقويم جوليان لتمثيل أي تاريخ قبل ذلك أكثر تعقيدًا. - Maciej Piechotka


إذا كنت لا تشعر بالسوء تجاه بعض التخمين ، دعني أقدم تفسيراً. وأنا لا أقصد "شخص ما تعيين قيمة لهراء" ، وهذا من الواضح ممكن دائما :)

عادة ما يستخدم نظام يونكس عدد الثواني منذ عام 1970. من ناحية أخرى ، يستخدم نظام ويندوز 1601 عامه الأول. إذا افترضنا (وهذا افتراض كبير!) أن المشكلة هي التحويل الخاطئ بين المرتين ، يمكننا أن نتصور أن التاريخ الذي كان من المفترض أن يتم تمثيله هو في الواقع في وقت ما في عام 2011 (1970 + 41) ، والتي تم تحويلها بشكل غير صحيح إلى 1640 (1601 + 41). تحرير: في الواقع ، أنا ارتكبت خطأ في ويندوز بدءا من العام. من الممكن أن يكون وقت الإنشاء الفعلي في عام 2010 ، أو أن هناك خطأ آخر (أخطاء متكررة شائعة جدًا في البرنامج: D).

بالنظر إلى أن هذا العام حدث ليكون آخر من تواريخ التتبع المرتبطة بالملف المعني ، أعتقد أنه تفسير معقول جدًا :)


16
2018-03-27 18:55



لذا يمكن أن يكون التاريخ مكتوبًا في Unix ، ولكن تتم قراءة بالتوقيت العالمي المنسق؟ - Fredy31
يستخدم Windows 1601 وليس 1600. - Joey
بعض القضايا مع هذه النظرية: وفقا للقطة ، فإن الملف قد تم إنشاؤه 11 يوما بعد كان آخر دخول. أيضاً ، يتم حساب الطوابع الزمنية لـ Windows في 100 nanoseconds ، بينما يكون وقت UNIX بالثواني. - Nolonar
Joey Ugh ، خطأي. وهذا يجعل الوضع أكثر سوءًا من النظرة الأولى: أعتقد أن الفكرة الأساسية نفسها يجب أن تعمل ، ولكن ربما هناك أخطاء أكثر من تلك التي توقعتها. أو ، بالطبع ، تم إنشاء الملف في عام 2010 ، وليس عام 2011. - Luaan
الثواني بين تاريخ ويندوز وتاريخ / وقت الملف المعروض هو 1.266.705.294. عندما تضاف إلى عهد يونكس ، هذه الغلة 2010-02-20 23:34:54 CESTوالذي كان يوم السبت. - SQB


كما كتبه آخرون ، عصر ويندوز هو في 1601-01-01 00:00.

عدد الثواني بين هذه الحقبة و filetime المعروضة ، هو 1.266.705.294.
إذا أضفنا ذلك إلى عصر يونكس ، نصل إلى 2010-02-20 23:34:54 CESTيوم السبت. هذا قبل سنة تقريبًا من تاريخ الوصول الأخير ، مما يجعله معقولًا إلى حد ما. لذلك ربما كان الطابع الزمني لـ Unix يتم تفسيره ضد الحقبة غير الصحيحة.


5
2018-03-30 07:47



الغريب هو أن عصر دوت نت هو 0001-01-01 00:00 UTC (وهو 1600 سنة مضت). نرى msdn.microsoft.com/en-us/library/... - Nayuki


كالعادة لهذه الأنواع من الأسئلة ، فإن مدونة Raymond Chen لديها إجابة في هذا الشأن من "لماذا هو تاريخ Win32 1 يناير 1601؟" الدخول من 6 مارس 2009:

ال FILETIME هيكل السجلات الوقت في شكل 100-nanosecond   فترات منذ 1 يناير 1601. لماذا تم اختيار هذا التاريخ؟

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

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


2
2018-03-30 06:12