2010-01-29 10 views
5

उन कारणों के लिए जो बहुत अस्पष्ट हैं, मेरे पास एक विशिष्ट समय का एक मिलीसेकंड प्रतिनिधित्व है और मेरे पास MySQL Timestamps से भरा एक MySQL डेटाबेस है और मैं उत्सुक हूं कि select * from myTable where time_stamp_column > 1264665600000; जैसे एसक्यूएल में मूल तुलना करना संभव है या उन पंक्तियों के साथ कुछ।क्या mysql TIMESTAMP को मिलीसेकंड से तुलना करना संभव है?

मैं कुछ परीक्षण चला रहा हूं और परिणाम बहुत अजीब हैं। यह शिकायत नहीं करता है लेकिन वह पंक्ति देता है जो मानदंडों के अनुरूप नहीं है।

अग्रिम धन्यवाद।

[संपादित करें] ठीक है अगर mySql में मिलीसेकंड का उपयोग करना एक गैर स्टार्टर है, तो तारीखों की तुलना करने का सबसे अच्छा तरीका क्या है, मानते हुए कि मैं मिलिस में शुरू कर रहा हूं और जावा में हूं।

उत्तर

6

आप मिलीसेकंड सटीकता नहीं मिलता है, लेकिन अपने उदाहरण के अंत में शून्य से पहचानने, आपको इसकी आवश्यकता नहीं हो सकती है।

यूनिक्स टाइमस्टैम्प में एक यूनिक्स टाइमस्टैम्प को कनवर्ट करने के लिए FROM_UNIXTIME का उपयोग करें। ऐसा लगता है कि यूनिक्स अवधि के बाद मिलीसेकेंड है, तो सिर्फ उन्हें 1000 से विभाजित कन्वर्ट करने के लिए:

SELECT * FROM myTable WHERE time_stamp_column > FROM_UNIXTIME(1264665600000/1000); 

आप के बाद से एसक्यूएल टाइम स्टांप, स्थानीय समय कर रहे हैं पूरी तरह से depressingly, यहाँ समय क्षेत्र/डीएसटी मुद्दों के लिए समायोजित करने के लिए हो सकता है।

+0

कोई नहीं ... आप कर रहे हैं ठीक है, मैं मिलीसेकंड सटीकता के बारे में बिल्कुल भी परवाह नहीं है, मैं भी नंबर पहले से ही परिमाण के 3 आदेश द्वारा कम में पारित कर सकते हैं ... मुझे लगता है कि काम करेंगे। –

3

जाहिर है यह एक ज्ञात बग है: Bug 8523Once upon a timestamp(milliseconds)...

देखें निष्पक्षता खातिर में, MySQL वास्तव में एक तरह से एक दशमलव क्षेत्र DECIMAL(17,3) में मिली और माइक्रो सेकंड बनाए रखने के लिए आपूर्ति की है, और यह भी queryable है जैसे कि यह एक टाइमस्टैम्प थे लेकिन क्यों 'isn DATETIME या TIMESTAMP फ़ील्ड में स्टोर करना संभव है?

3

नहीं, TIMESTAMP और DATETIME कॉलम दुर्भाग्य से मिलीसेकंद सटीकता के साथ मानों को संग्रहीत नहीं करते हैं। इसके लिए एक कार्य-आसपास एक बिगिनट कॉलम का उपयोग करना है, और आपके टाइमस्टैम्प की उचित संख्या मिलीसेकंद स्थानों के साथ है, यानी। 1264808431000. दुर्भाग्य से, इसका मतलब है कि आपके आवेदन में या MySQL में कोई तुलना तर्क एक बिगिनट आधार पर होना होगा।

+2

मैं इस एक नहीं मिल रहा है व्यक्तिगत रूप से दोष, बिल्कुल। इंटीग्रर्स डाटाबेस और डेटा एक्सेस परतों की तारीखों की गड़बड़ी की तुलना में सरल और अधिक समान हैं। यह वैचारिक रूप से शुद्ध नहीं हो सकता है, लेकिन कोई व्यावहारिक नकारात्मक नहीं है; यह हर बार मेरे लिए आईएनटी/बिगिनट टाइमस्टैम्प है। – bobince

+0

@bobince - मैं इसे समय पर एक सा बोझल मिल जाए, और यह यह कठिन आरडीबीएमएस-विशिष्ट तिथि कार्यों में से कुछ का उपयोग करने के पड़ता है। दूसरी तरफ, कभी-कभी आप INTs का उपयोग करके रिकॉर्ड पर बाइट या दो बचा सकते हैं। यह एक काफी प्रासंगिक निर्णय है। – zombat

+0

हाँ, मैं नहीं यह भंडारण बचत के लिए कर रहा हूँ, मैं पूर्वानुमान के लिए यह कर रहा हूँ: dateformats और समय क्षेत्रों के बारे में चिंता करने की जो कुछ मैं यूआई परत का हिस्सा मानते हैं और कुछ भी नहीं मैं अपने बैकएंड डेटा स्टोर के पास कहीं भी चाहते हैं नहीं होने ।मैं यह वास्तव में मूर्ख सिर्फ इसलिए MySQL इसे वापस एक टाइमस्टैम्प में भंडारण के लिए परिवर्तित कर सकते हैं (केवल एक mucked-अप स्थानीय समय क्षेत्र के साथ) एक स्ट्रिंग में मेरी टाइमस्टैम्प परिवर्तित मानते हैं। – bobince

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