1641 में कोई फ़ाइल 'बनाई' कैसे जा सकती है?

75

कुछ साल पहले, मैं इस फाइल पर हमारे फाइलर पर ठोकर खाई थी।

और मुझे आश्चर्य है कि यह कैसे कह सकता है कि यह 1641 में बनाई गई है? जहाँ तक मुझे पता है, पीसी पर समय 1 जनवरी, 1970 से सेकंड की संख्या द्वारा परिभाषित किया गया है। यदि वह सूचकांक बाहर निकलता है, तो आप 31 दिसंबर, 1969 (शायद सूचकांक -1 कहते हैं) प्राप्त कर सकते हैं, लेकिन मैं इस पर स्टम्प्ड हूं प्रतीत होता है बेतरतीब तारीख, कि संयुक्त राज्य अमेरिका के संस्थापक भी भविष्यवाणी करता है।

तो 1641 में एक फाइल को दिनांकित कैसे किया जा सकता था?

पुनश्च: तिथियाँ फ्रेंच में हैं। फेवरियर फरवरी है।

filesystems

— Fredy31
स्रोत

29

"जहाँ तक मुझे पता है, पीसी पर समय 1 जनवरी, 1970 से सेकंड की संख्या द्वारा परिभाषित किया गया है।" - यहां तक कि उन प्रणालियों के लिए जहां 1970 से पहले की तारीखों को आसानी से उस संख्या ( यूनिक्स टाइमस्टैम्प के रूप में जाना जाता है ) को नकारात्मक बनाकर दर्शाया जाता है । उदाहरण के लिए, यूनिक्स समय -1000000000 1938-04-24 22:33:20 से मेल खाती है।

— Marcelm

1

@marcelm हां, लेकिन 32-बिट पूर्णांकों की सीमित सीमा के कारण 1901 में न्यूनतम संभव तारीख है।

— slhck

14

@ एसएलएचएचके: मुझे लगता है कि मार्सेलम 64-बिट टाइमस्टैम्प मान रहा था, क्योंकि यही वर्तमान यूनिक्स / लिनक्स फाइल सिस्टम, कर्नेल और उपयोगकर्ता-अंतरिक्ष सॉफ्टवेयर उपयोग है। की परिभाषा के लिए clock_gettime(2)मैन पेज देखें struct timespec, जो कि है statऔर अन्य सिस्टम कॉल उपयोगकर्ता-अंतरिक्ष और कर्नेल के बीच टाइमस्टैम्प को पास करने के लिए उपयोग करते हैं। यह time_tसेकंड में, और long tv_nsecनैनोसेकंड के साथ एक संरचना है। 64-बिट सिस्टम पर, दोनों 64-बिट हैं, इसलिए पूरी टाइमस्टैम्प 128 बिट्स (16 बाइट्स) है। (बहुत अधिक विवरण के लिए क्षमा करें, मैं भाग गया।)

— पीटर कॉर्डेस

3

आपको एक अच्छा जवाब मिला कि कैसे 1600 के दशक में एक तारीख को फाइल पर मुहर लगाई जा सकती है, अब यह सोचने का समय है कि यह कैसे हुआ। मैं उस wp फ़ाइल की सामग्री को बहुत बारीकी से देखूंगा कि इसमें क्या जोड़ा गया है, क्योंकि यह कैसे हुआ, इस पर प्रकाश डाला जा सकता है। मैं स्थापित प्लगइन्स को देखूंगा और सत्यापित करूंगा कि कोई भी छायादार न हो। मैं कुछ सोच रहा हूँ कि उस फाइल को संशोधित किया गया है और फ़ाइल को संशोधित करने के लिए मैन्युअल रूप से संशोधित / बनाई गई तिथियों पर मुहर लगाने की कोशिश की गई है, लेकिन एक विंडोज़ समय के बजाय एक यूनिक्स समय निर्दिष्ट किया गया है।

— थॉमस कार्लिस्ले

2

किंग लुई तेरहवें जस्ट पीएचपी को शाही लाइन की प्रतिबद्धता का प्रदर्शन कर रहे थे?

— जेसी स्लीसर

106

1600 के दशक से तारीख क्यों संभव है?

विंडोज फाइल संशोधन टाइमस्टैम्पों को स्टोर नहीं करता है जैसे कि यूनिक्स सिस्टम करते हैं । के अनुसार विंडोज देव केंद्र (जोर मेरा):

एक फ़ाइल समय एक 64-बिट मान है जो 100-नैनोसेकंड अंतराल की संख्या का प्रतिनिधित्व करता है जो 12:00 पूर्वाह्न 1 जनवरी, 1601 समन्वित यूनिवर्सल टाइम (यूटीसी) के बाद से समाप्त हो गया है । सिस्टम फाइल को रिकॉर्ड करता है जब एप्लिकेशन बनाते हैं, एक्सेस करते हैं, और फाइलों पर लिखते हैं।

तो, यहां एक गलत मान सेट करके, आप आसानी से 1600 के दशक से तारीखें प्राप्त कर सकते हैं।

बेशक, एक और महत्वपूर्ण सवाल है: यह मूल्य कैसे निर्धारित किया गया था? वास्तविक तारीख क्या है? मुझे लगता है कि आप कभी भी इसका पता नहीं लगा पाएंगे, क्योंकि फाइल सिस्टम ड्राइवर में बस एक गणना त्रुटि हो सकती है। एक अन्य उत्तर यह परिकल्पना करता है कि वास्तव में एक यूनिक्स टाइमस्टैम्प की व्याख्या विंडोज टाइमस्टैम्प के रूप में की जाती है, लेकिन वे वास्तव में अलग-अलग अंतराल (सेकंड बनाम नैनोसेकंड) पर गणना करते हैं।

यह वर्ष 2038 समस्या से कैसे संबंधित है?

64-बिट डेटा प्रकार के उपयोग का अर्थ है कि विंडोज (आम तौर पर) वर्ष 2038 की समस्या से प्रभावित नहीं है जो कि पारंपरिक यूनिक्स सिस्टम के पास है, क्योंकि यूनिक्स ने शुरू में 32-बिट पूर्णांक का उपयोग किया था, जो कि 64-बिट पूर्णांक की तुलना में जल्द ही समाप्त हो जाता है - विंडोज है। (यह यूनिक्स के संचालन के दौरान सेकंड और विंडोज माइक्रो / नैनोसेकंड पर काम करने के बावजूद है।)

32-बिट प्रोग्राम का उपयोग करते समय विंडोज अभी भी प्रभावित होता है जो कि विज़ुअल स्टूडियो के पुराने संस्करणों के साथ संकलित किया गया था।

नए यूनिक्स ऑपरेटिंग सिस्टम ने पहले ही डेटा प्रकार को 64 बिट तक विस्तारित कर दिया है, इस प्रकार समस्या से बचा है। (वास्तव में, चूंकि यूनिक्स टाइमस्टैम्प सेकंडों में काम करते हैं, इसलिए नए रैपराउंड की तारीख अब से 292 बिलियन वर्ष होगी।)

अधिकतम तिथि कौन सी निर्धारित की जा सकती है?

जिज्ञासु लोगों के लिए - यह कैसे गणना करें:

एक 64-बिट पूर्णांक में संभावित मानों की संख्या रहे हैं 2 ⁶³ 1 = 9223372036854775807 - ।
प्रत्येक टिक 100 नैनोसेकंड का प्रतिनिधित्व करता है, जो 0.1 0.00s या 0.0000001 एस है।
अधिकतम समय सीमा 922337203685474780807 001 0.0000001 सेकेंड होगी , इसलिए सैकड़ों सेकंड।
एक घंटे में 3600 सेकंड होते हैं, एक दिन में 86400 सेकंड होते हैं, और एक साल में 365 दिन होते हैं, इसलिए एक साल में 86400 36 365 s = 31536000 होते हैं । यह निश्चित रूप से, केवल एक औसत, लीप वर्ष, लीप सेकंड या किसी भी कैलेंडर को अनदेखा करता है, जो भविष्य के पोस्टपॉलेक्यप्टिक शासनों को शेष पृथ्वी पर तय कर सकता है।
922337203685474780807 001 0.0000001 s / 31536000 s 24 29247 वर्ष
@corsiKaबताते हैं कि हम लीप वर्षों को कैसे घटा सकते हैं: 29247/365/4 ract 20
तो आपका अधिकतम वर्ष 1601 + 29247 - 20 = 30828 है ।

कुछ लोगों ने वास्तव में इसे स्थापित करने की कोशिश की है और उसी वर्ष के साथ आए हैं।

— slhck
स्रोत

7

रिकॉर्ड के लिए, यूनिक्स (या कम से कम लिनक्स) पहले से ही 64-बिट आर्किटेक्चर पर कर्नेल / फाइल सिस्टम के लिए 2038 समस्या को हल कर चुका है, जहां time_t64-बिट प्रकार है, इसलिए उम्मीद है कि time_tपूर्णांक प्रकार के बजाय अनुप्रयोगों का उपयोग अभी भी 32-बिट है। समतल टाइमस्टैम्प होगा ... वैसे भी, किसी को भी समस्या की स्थिति के बारे में उत्सुक था, यह ज्यादातर विरासत 32-बिट को छोड़कर हल किया गया है। आईडीके अगर 32-बिट एआरएम 2038 में अभी भी प्रासंगिक होगा, लेकिन यह कम से कम एक एबीआई परिवर्तन को मजबूर करेगा। 32-बिट x86 बहुत यूनिक्स दुनिया में चला गया है; यह केवल विंडोज है जहां 32-बिट कोड अभी भी आम है।

— पीटर कॉर्डेस

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— जर्नीमैन गीक

1

वीएमएस समय " एक 64-बिट मान है जो 100-नैनोसेकंड अंतराल की संख्या का प्रतिनिधित्व करता है जो 17-नवंबर -1858 के बाद से समाप्त हो गए हैं। " :)

— रॉनजॉन

वर्ष 30k है ... आश्चर्यजनक रूप से कम

— जॉन ड्वोरक

2

@DonaldDuck ब्लॉग s.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913 और लगभग 1600 लोग अभी भी जूलियन कैलेंडर का उपयोग कर रहे थे, इससे पहले कि किसी भी तारीख का प्रतिनिधित्व अधिक जटिल हो।

— मैकीज पीचोटका

16

यदि आप कुछ अनुमान लगाने में बहुत बुरा महसूस नहीं करते हैं, तो मुझे एक स्पष्टीकरण दें। और मेरा मतलब यह नहीं है "किसी ने बकवास करने के लिए मूल्य निर्धारित किया", यह स्पष्ट रूप से हमेशा संभव है :)

यूनिक्स समय आमतौर पर 1970 के बाद से सेकंड की संख्या का उपयोग करता है। दूसरी ओर विंडोज, 1601 को अपने शुरुआती वर्ष के रूप में उपयोग करता है। इसलिए यदि हम मान लेते हैं (और यह एक बड़ी धारणा है!) कि समस्या दो बार के बीच गलत रूपांतरण है, तो हम सोच सकते हैं कि जिस तारीख का प्रतिनिधित्व किया जाना था वह वास्तव ~~में 2011 (1970 + 41) में है, जिसे गलत तरीके से परिवर्तित किया गया है 1640 (1601 + 41) तक~~ । संपादित करें: वास्तव में, मैंने विंडोज के शुरुआती वर्ष में एक गलती की। यह संभव है कि वास्तविक निर्माण समय 2010 में था, या इसमें एक और त्रुटि शामिल थी (ऑफ-बाय-वन त्रुटियां सॉफ्टवेयर में बहुत आम हैं:)।

यह देखते हुए कि यह वर्ष प्रश्न में फ़ाइल के साथ जुड़े ट्रैकिंग तिथियों में से एक है, मुझे लगता है कि यह एक बहुत प्रशंसनीय स्पष्टीकरण है :)

— Luaan
स्रोत

तो यह हो सकता है कि तारीख यूनिक्स में लिखी गई थी, लेकिन यूटीसी में पढ़ा जाता है?

— फ्रेड

विंडोज 1601 का उपयोग करता है, 1600 का नहीं।

— जोए

3

उस सिद्धांत के साथ कुछ समस्याएँ: स्क्रीनशॉट के अनुसार, फ़ाइल को अंतिम एक्सेस के 11 दिन बाद बनाया गया होगा । इसके अलावा, विंडोज टाइमस्टैम्प की गिनती 100 नैनोसेकंड में की जाती है, जबकि UNIX का समय सेकंड में है।

— नोलोनार

2

@ जोये ऊ, मेरी गलती। यह फिट को पहली नज़र में बहुत बुरा बना देता है :) मुझे लगता है कि एक ही मूल विचार अभी भी काम करना चाहिए, लेकिन शायद इससे अधिक त्रुटियां हैं जो मैंने मान लीं। या, निश्चित रूप से, फ़ाइल को 2010 में बनाया गया था, 2011 में नहीं।

— लुआॅन

2

Windows युग और दिखाए गए फ़ाइल दिनांक / समय के बीच सेकंड 1.266.705.294 है । जब यूनिक्स युग में जोड़ा गया, तो यह 2010-02-20 23:34:54 CEST है , जो एक शनिवार था।

— SQB

5

जैसा कि दूसरों द्वारा लिखा गया है, विंडोज युग 1601-01-01 00:00 पर है ।

उस काल और प्रदर्शित जीवनकाल के बीच सेकंड की संख्या 1.266.705.294 है ।
अगर हम यूनिक्स युग में इसे जोड़ते हैं, तो हम 2010-02-20 23:34:54 CEST , एक शनिवार को आते हैं। यह अंतिम अभिगमन तिथि से लगभग एक वर्ष पहले का है, जो इसे कुछ हद तक प्रशंसनीय बनाता है। तो यह गलत युग के खिलाफ व्याख्या की गई यूनिक्स टाइमस्टैम्प हो सकता है।

— SQB
स्रोत

अजीब तरह से, .NET युग 0001-01-01 00:00 UTC (जो 1600 साल पहले है)। देखें msdn.microsoft.com/en-us/library/...

— Nayuki

2

इन प्रकार के सवालों के लिए हमेशा की तरह, रेमंड चेन के ब्लॉग का इस बारे में जवाब है कि "क्यों Win32 की अवधि 1 जनवरी, 1601 है?" 6 मार्च, 2009 से प्रवेश:

FILETIMEसंरचना 1 जनवरी के बाद 100-nanosecond अंतराल के रूप में समय रिकॉर्ड, 1601. क्यों उस तारीख में चुना गया था?

ग्रेगोरियन कैलेंडर 400-वर्षीय चक्र पर संचालित होता है, और 1601 चक्र का पहला वर्ष है जो उस समय सक्रिय था जब Windows NT डिजाइन किया जा रहा था। दूसरे शब्दों में, यह गणित को अच्छी तरह से बाहर लाने के लिए चुना गया था।

मेरे पास वास्तव में डेव कटलर का ईमेल है जो इसकी पुष्टि करता है।

— ErikF
स्रोत