2011-09-16 18 views
14

मेरे पास एक ऐप है जो एक प्रारंभिक तिथि और एसक्यूएल चयन की समाप्ति तिथि के लिए एक सीमा के रूप में टाइमस्टैम्प लेता है, मैं साल के पहले सोमवार से मूल्यों और सप्ताह संख्या के रूप में इस वर्ष के हफ्तों के साथ एक हैशपैप तैयार करना चाहता हूं चाबियाँ। मुझे टाइमस्टैम्प के साथ काम करना वाकई मुश्किल लगता है और मुझे दिन में वृद्धि के लिए 86,400,000 सेकेंड जोड़ने के बारे में बहुत अच्छा नहीं लगता है, क्योंकि यह लीप दिनों, घंटों, सेकंड के लिए जिम्मेदार नहीं है।मैं 14 दिनों तक java.sql.Timestamp कैसे बढ़ा सकता हूं?

मैं 13 दिनों में 23 घंटे, 59 मिनट और 59 सेकंड जोड़ने की योजना बना रहा हूं ताकि मैं सप्ताह में स्टार्ट तिथि को कुंजी के रूप में देख सकूं, फिर समाप्ति तिथि प्राप्त करने के लिए प्रारंभ तिथि का उपयोग करें।

तो मैं कुछ इस तरह प्राप्त करने की कोशिश करने के लिए देख रहा हूँ:

Week startDate    endDate 
1  2011-01-03 00:00:00 2011-01-16 23:59:59 
2  2011-01-17 00:00:00 2011-01-30 23:59:59 

मानचित्र और पिछले एक में पहले दो स्तंभों के साथ यह देख अप के बाद की गणना की जा रही है। मैं java.sql.Timestamp को सुरक्षित रूप से कैसे बढ़ा सकता हूं?

+0

समस्या सिर्फ आप के बारे में चिंता करने की ज़रूरत होगी छलांग सेकंड है, और उन एक बार हर कुछ वर्षों होता है। यदि आपका कार्यक्रम 1 9 70 से चल रहा था तो यह कुल 24 सेकंड से बंद हो जाएगा। 86.4 एम सेकेंड जोड़ने की आपकी योजना पूरी तरह व्यवहार्य है। – corsiKa

+0

कैलेंडर या जोडा के साथ काम करने के बारे में कैसे? http://joda-time.sourceforge.net/ –

+0

मुझे लगता है कि वास्तविक सवाल यह है कि ... क्या आपने इसे अपने ऐप के लिए अवरोधक के रूप में पहचाना है? यदि आपने नहीं किया है, तो बस इसके साथ जाओ। यदि यह एक समस्या है, तो यह स्वयं उपस्थित होगा और आप इससे निपट सकते हैं। – corsiKa

उत्तर

7

यह ध्यान देने योग्य है कि 14 दिन हमेशा 14 * 24 * 3600 सेकंड नहीं होते हैं। जब आपके पास डेलाइट बचत होती है, तो यह एक घंटे छोटा या लंबा हो सकता है। ऐतिहासिक रूप से यह उससे कहीं अधिक जटिल हो सकता है।

इसके बजाय मैं समय क्षेत्र निर्भर गणना करने के लिए जोडाटाइम या कैलेंडर का उपयोग करने का सुझाव दूंगा।

+1

क्या वास्तव में यह मायने रखता है? जब तक आप यूटीसी का उपयोग कर रहे हों, आप इस समस्या में भाग नहीं लेंगे। – corsiKa

+1

एसक्यूएल ज्यादातर यूटीसी का उपयोग नहीं करता है। विशेष रूप से यदि आप स्पष्ट रूप से इसे पूरा नहीं करते हैं। –

+0

यदि आप जीएमटी या किसी भी टाइमज़ोन का उपयोग डेलाइट सेविंग के बिना कर रहे हैं तो यह कोई समस्या नहीं है। मैं ध्वजांकित करना चाहता था कि 14 दिनों में एक दिन हो सकता है जिसमें 24 घंटे नहीं हैं। जावा जीएमटी जैसे लीप सेकेंड का समर्थन नहीं करता है लेकिन यूटीसी करता है। ;) –

36
java.sql.Timestamp ts = ... 
Calendar cal = Calendar.getInstance(); 
cal.setTime(ts); 
cal.add(Calendar.DAY_OF_WEEK, 14); 
ts.setTime(cal.getTime().getTime()); // or 
ts = new Timestamp(cal.getTime().getTime()); 

यह सही ढंग से अपने डिफ़ॉल्ट समय क्षेत्र में दिन के उजाले समय संक्रमण को पूरा करेगा। आवश्यकता होने पर आप कैलेंडर क्लास को एक अलग टाइमज़ोन का उपयोग करने के लिए कह सकते हैं।

+0

यदि आपके वीएम की एक अद्यतन सूची है तो यह केवल डेलाइट बचत के लिए सही ढंग से खाता होगा। जोडाटाइम इसके लिए एक मानक स्रोत के उपयोग की अनुमति देता है - माना जाता है कि इसके लिए वीएम अपडेट ऐतिहासिक रूप से धीमे हैं। –

+1

मुझे संदेह है कि धीमे अपडेट का एक कारण यह है कि "एंटरप्राइज़" उपयोगकर्ता कम से कम 10 साल के जेवीएमएस पर रहते हैं ... दूसरी तरफ, अधिकांश ओएस टाइमज़ोन जानकारी की एक सूची रखने में कामयाब रहता है जिसमें सभी जानकारी है जरूरत है। जेआर वास्तव में इसका उपयोग करना चाहिए। मेरे लिनक्स लैपटॉप पर, यह 24 99 तक सेटअप हो रहा है ... – KarlP

2
private Long dayToMiliseconds(int days){ 
    Long result = Long.valueOf(days * 24 * 60 * 60 * 1000); 
    return result; 
} 

public Timestamp addDays(int days, Timestamp t1) throws Exception{ 
    if(days < 0){ 
     throw new Exception("Day in wrong format."); 
    } 
    Long miliseconds = dayToMiliseconds(days); 
    return new Timestamp(t1.getTime() + miliseconds); 
} 
1

जावा 8

Timestamp old; 
ZonedDateTime zonedDateTime = old.toInstant().atZone(ZoneId.of("UTC")); 
Timestamp new = Timestamp.from(zonedDateTime.plus(14, ChronoUnit.DAYS).toInstant()); 
संबंधित मुद्दे