2011-01-05 8 views
11

मैं ऐसे प्रोग्राम पर काम कर रहा हूं जो फाइलों से दिनांक मेटाडेटा रिकॉर्ड करता है, जैसे सृजन समय, अंतिम संशोधित समय इत्यादि। कार्यक्रम का एक पुराना संस्करण वीबीए में लिखा गया है, और सवाल में फ़ाइल के लिएIO.File.GetLastAccessTime एक घंटे से बंद है

Public Function GetFileLastAccessTime(ByVal FilePath As String) As Date 
    Dim fso As New Scripting.FileSystemObject 
    Dim f As Scripting.File 
    Set f = fso.GetFile(FilePath) 
    GetFileLastAccessTime = f.DateLastAccessed 
End Function 

आउटपुट:: कुछ इस तरह करता है

?getfilelastaccesstime("SomePath") 
7/30/2010 2:16:07 PM 

मूल्य मैं Windows पलीता में फ़ाइल गुणों से मिलता है। ख़ुशी।

मैं इस कार्यक्षमता को VB.Net ऐप पर पोर्ट कर रहा हूं। नया कोड:

Public Function GetLastAccessTime(ByVal FilePath As String) As Date 
    Return IO.File.GetLastAccessTime(FilePath) 
End Function 

सरलता स्वयं ही। आउटपुट:

?GetLastAccessTime("SomePath") 
#7/30/2010 3:16:07 PM# 

एक घंटे बाद।

दोनों कार्य एक ही मशीन पर चल रहे हैं, उसी फ़ाइल को जांच रहे हैं। मैंने एक ही परिणाम के साथ IO.FileInfo कक्षा का उपयोग करने का भी प्रयास किया है। मैंने हजारों फाइलों की जांच की है और वे सभी एक घंटे से दूर हैं। निर्माण समय और अंतिम संशोधित समय के लिए अन्य दिनांक गुण भी एक घंटे से बंद हैं।

सहायता!

मैं मूल पोस्ट में उल्लेख करना भूल गया, कंप्यूटर का समय क्षेत्र सीएसटी है, और डेलाइट बचत समय वर्तमान में प्रभावी नहीं है।

मैंने विंडोज 7 64 बिट और विंडोज एक्सपी 32 बिट पर समस्या का पुन: उत्पन्न किया है।

धन्यवाद।

1/6/2011 अद्यतन:

हर किसी के लिए धन्यवाद, जिन्होंने यूटीसी से वांछित समय उचित समय क्षेत्र ऑफसेट का उपयोग कर की गणना करने की कोशिश कर का सुझाव दिया। इस समय मैं ऐसा करने का जोखिम नहीं ले रहा हूं। इस विशेष व्यावसायिक आवश्यकता के लिए, यह कहना बेहतर है कि डेट वैल्यू वह नहीं है जिसे आप उम्मीद करते हैं क्योंकि यह एपीआई काम करता है। अगर मैं इसे "ठीक करने" का प्रयास करता हूं तो मेरा स्वामित्व है, और मैं नहीं चाहूंगा।

बस किक के लिए मैंने अच्छे पुराने स्क्रिप्टिंग का उपयोग करने की कोशिश की। इंटरफ़ेस के माध्यम से FileSystemObject। यह अपेक्षित परिणाम देता है जो Windows Explorer के साथ सहमत हैं, System.IO की तुलना में लगभग 5x प्रदर्शन जुर्माना के साथ। यदि यह पता चला है कि मुझे उन तिथियों को प्राप्त करना होगा जो विंडोज एक्सप्लोरर के पास हैं, मैं बुलेट काट दूंगा और इस मार्ग पर जाऊंगा।

एक और प्रयोग मैंने कोशिश की सी # के माध्यम से kernel32 में GetFileTime एपीआई समारोह के लिए सीधे जा रहा था:

[DllImport("kernel32.dll", SetLastError = true)] 
private static extern bool GetFileTime(
IntPtr hFile, 
ref FILETIME lpCreationTime, 
ref FILETIME lpLastAccessTime, 
ref FILETIME lpLastWriteTime 
); 

यही समान व्यवहार System.IO था के परिणामस्वरूप, समय Windows Explorer से एक घंटे के द्वारा किया गया था ।

फिर से सभी को धन्यवाद।

+2

मुझे डेलाइट सेविंग टाइम इश्यू की तरह लगता है – Flipster

+0

अंतिम एक्सेस समय में लगभग 1 घंटा की ग्रैन्युलरिटी है। साथ ही, ध्यान रखें कि डिफ़ॉल्ट रूप से विंडोज विस्टा और ऊपर में, [अंतिम एक्सेस टाइम मान डिफ़ॉल्ट रूप से एनटीएफएस वॉल्यूम्स पर अपडेट नहीं किया गया है] (http://blogs.technet.com/b/filecab/archive/2006/11/07 /disabling-last-access-time-in-windows-vista-to-improve-ntfs-performance.aspx)। –

+0

डीएसटी अब प्रभावी नहीं है लेकिन यह * प्रभाव में था जब फ़ाइल को अंतिम बार संशोधित किया गया था। कौन सही है? उस प्रश्न पूछने से बचने के लिए यूटीसी में काम करें। –

उत्तर

3

मैं इसे XP/Win2k3/Vista पर .NET 4.0 और 2.0/3.5 का उपयोग करके पुन: उत्पन्न कर सकता हूं।

मुद्दा यह है कि डीएसटी अब एक अलग राज्य में था, और .NET इस अंतर को एक्सप्लोरर और Scripting.FileSystemObject पर अलग-अलग संसाधित कर रहा है।

(आप ने वही समस्या जब एक ज़िप फ़ाइल से फ़ाइलों को निकालने जब डीएसटी फ़ाइलें ज़िप थे करने के लिए अलग है देख सकते हैं।)

वाया परावर्तक, कारण नेट गैर नेट कोड रास्तों से अलग है IO.File (और IO.FileInfo) में सभी तीन स्थानीय डेटास्टैम्प को यूटीसी डेटास्टैम्प प्राप्त करने और .ToLocalTime लागू करने के रूप में लागू किया गया है, जो यूटीसी समय के लिए स्थानीय टाइमज़ोन में डीएसटी हो रहा था या नहीं, इस पर आधारित ऑफसेट निर्धारित करता है।

मैंने पिछले साल 1 जुलाई को तारीख को बदलकर, एक फ़ाइल बनाने और टाइमस्टैम्प को देखकर, जब मैं वर्तमान दिनांक (16 मार्च) (मैं दक्षिण ऑस्ट्रेलिया में हूं, तो हम डीएसटी में हैं) अब और 1 जुलाई को नहीं थे), और विंडोज (और संभवतः FileSystemObject) डीएसटी को जगह अब में जोड़ता है, इसलिए वास्तव में प्रदर्शित समय वास्तव में बदलता है।

तो संक्षेप में, .NET अधिक सही है।

लेकिन तुम गलत है, लेकिन एक्सप्लोरर के रूप में ही, दिनांक उपयोग करना चाहते हैं:

Public Function GetLastAccessTime(ByVal FilePath As String) As Date 
    Return IO.File.GetLastAccessTimeUtc(FilePath) _ 
     .Add(TimeZone.CurrentTimeZone.GetUtcOffset(Now)) 
End Function 

यह Raymond Chen's blog पर चर्चा की गई (जहां सार है: .NET intuitively सही लेकिन हमेशा उलटी नहीं जा सकती, और Win32 सख्ती से सही और उलटा है)।

0

GetLastAccessTimeUtc आज़माएं क्योंकि मुझे संदेह है कि यह स्थानीय समय और डेलाइट बचत का मुद्दा है।

0

अच्छा ... मैं इसे अपने विंडोज 7 कंप्यूटर पर पुन: पेश नहीं कर सकता, लेकिन यह एक दिन प्रकाश बचत समस्या की तरह लगता है।आप की तरह कुछ कोशिश कर सकते हैं:

Dim dt As DateTime = System.IO.File.GetLastAccessTime(FilePath) 
    If Not dt.IsDaylightSavingTime() Then 
     dt.AddHours(1) 
    End If 

प्रयोग है कि क्या जोड़ें/घटाना करने के लिए के रूप में आवश्यक हो सकता है ...

+0

मैं मूल पोस्ट में उल्लेख करना भूल गया, कंप्यूटर का समय क्षेत्र सीएसटी है, और डेलाइट बचत समय वर्तमान में प्रभावी नहीं है। धन्यवाद। –

+1

@Roger - यदि आप फ़ाइल पर मैन्युअल रूप से मान सेट करने के लिए VB.Net के SetLastAccessTime का उपयोग करते हैं और फिर VBA में मान पढ़ते हैं तो क्या होता है? क्या वीबीए और विंडोज एक्सप्लोरर आपके कोड में सेट किए गए एक ही समय के साथ दिखाते हैं? एक दिलचस्प परीक्षण हो सकता है। – Peter

0

अगर आप वर्तमान संस्कृति का उपयोग तारीख उत्पादन ?, जैसे फ़ॉर्मेट करने के लिए क्या मिलता है,

Dim dt As DateTime = System.IO.File.GetLastAccessTime(FilePath) 
Dim dateText As String = dt.ToString(System.Globalization.CultureInfo.CurrentCulture) 
+0

साफ विचार! दुर्भाग्यवश यह पहले जैसा ही गलत समय लौटा। –

0

जैसा कि पहले ही मुझे लगता है कि इसका जवाब UTC समय का उपयोग है, और यदि आप क्या समय है कि 'स्थानीय स्तर पर' जानने की जरूरत स्थानीय है कि विशेष रूप से डेलाइट सेविंग टाइम के आधार पर समय से काम करते हैं उल्लेख किया वर्तमान संस्कृति की जानकारी का उपयोग कर समय पर इंगित करें। काफी तुच्छ नहीं है लेकिन कम से कम एक काम है?

0
Public Function GetLastAccessTime(ByVal FilePath As String) As Date 
    Return IO.File.GetLastAccessTime(FilePath).ToLocalTime() 
End Function 
0

आप पता लगा सकते हैं निम्नलिखित कोड का उपयोग कर ऑफसेट:

'... 
Dim datetimeNow as DateTime = DateTime.Now 
Dim localOffset as TimeSpan = datetimeNow - now.ToUniversalTime() 
'... 

अपना समय

0

VBA को localOffset जोड़े समय क्षेत्रों के साथ बेला के लिए तो यह जीत एपीआई से कुछ मानक का उपयोग किया जाना चाहिए की अनुमति नहीं है।मैं प्रयोग सुझाव है:

  • दिनांक & समय संपत्तियों के लिए जाने के लिए और सबसे पहले यह सुनिश्चित डेलाइट सेविंग टाइम बंद है बनाने के लिए और परिणामों की तुलना
  • तो कई अलग अलग लोगों के लिए समय क्षेत्र बदलने के और देखते हैं कि दोनों आवेदनों व्यवहार करते हैं
  • चयन यूटीसी टाइमज़ोन और देखें कि

क्या आपको कभी भी अंतिम बार पहुंचने वाला समय मिलेगा?

1

डेलाइट बचत समय मेरे लिए अपराधी था। डेटाडेट में उस समय को शामिल किया गया था जिसे मुझे समायोजित करने की आवश्यकता थी, लेकिन यह जांच कर रहा था कि "अब()" (या जैसा ऊपर दिखाया गया है, कोई पैरामीटर समान नहीं है) डीएसटी है, यह तय है।

If TimeZone.CurrentTimeZone.IsDaylightSavingTime(Now()) = True Then 
    datDate = DateAdd(DateInterval.Hour, -1, datDate) 
End If 
+0

मुझे पता है कि लगभग कहीं भी 1 घंटे से अधिक की डेलाइट बचत ऑफसेट नहीं है, लेकिन यह '= True' के साथ संयुक्त है और मैंने इसे देखकर कई बार क्लिक किया है ... –

0

मुझे इस समस्या का सामना करना पड़ा, और मुझे विश्वास है कि मैं समझ रहा हूं कि क्या हो रहा है।

मेरे पास पावरशेल स्क्रिप्ट और एक सीएमडी स्क्रिप्ट है (डीआईआर कमांड का उपयोग करके) जो फ़ाइलों की संशोधित दिनांक/समय की रिपोर्ट करता है। डेलाइट से मानक समय में हुए हालिया परिवर्तन के बाद, पावरहेल स्क्रिप्ट डीआईआर कमांड की तुलना में एक घंटे बाद समय परिवर्तन से पहले बनाई गई फाइलों के समय की रिपोर्ट कर रही थी। विंडोज एक्सप्लोरर ने पावरहेल के रूप में एक ही समय की सूचना दी।

चूंकि एनटीएफएस फ़ाइल टाइमस्टैम्प यूटीसी के रूप में संग्रहीत हैं, इसलिए वे स्थानीय समय पर प्रदर्शन/आउटपुट के लिए स्वीकार किए जाते हैं। ऐसा प्रतीत होता है कि समय प्रदर्शित करने पर डीआईआर कमांड यूटीसी से वर्तमान समय क्षेत्र ऑफसेट का उपयोग करता है (+8, क्योंकि मैं प्रशांत समय क्षेत्र में हूं और अब यह मानक समय है), जबकि पावरहेल (और विंडोज एक्सप्लोरर) स्थानीय समय ऑफसेट का उपयोग कर रहा है यह टाइमस्टैम्प के समय प्रभाव में था (जब फाइलें बनाई गई थीं), जो यूटीसी +7 थी, क्योंकि यह अभी भी डेलाइट टाइम था।

मुझे लगता है कि पावरहेल रूपांतरण सही है। मुझे लगता है कि आप किसी भी तरह से बहस कर सकते हैं, लेकिन यदि आप डेलाइट टाइम चेंज से पहले और बाद में टाइमस्टैम्प देखते हैं, तो पावरहेल परिणाम समान होंगे, जबकि डीआईआर परिणाम अलग होंगे, और असंगत होंगे।

संबंधित मुद्दे