मैंने हाल ही में पाया है कि उपयोग किए जा रहे डेटाबेस ड्राइवर के आधार पर, jOOQ डेटटाइम पार्सिंग में कुछ अजीब व्यवहार प्रदर्शित कर सकता है। jOOQ ऑफ़सेट दिनांक समय को Z (UTC) के रूप में लौटाता है, भले ही वह न हो
विशेष रूप से, मेरे मामले में, एक अलग पोस्टग्रेज ड्राइवर का उपयोग करने के परिणामस्वरूप DefaultBinding.java एक कैलेंडर ऑब्जेक्ट प्राप्त कर रहा है जिसमें टाइमस्टैम्प है, लेकिन पार्स करने के लिए उस पर toString को कॉल करना। पता चला, toString टाइमज़ोन को प्रिंट नहीं करता है, फिर jOOQ ने अनुमान लगाया कि यह स्थानीय समय में था।
मेरे लिए, DefaultBinding.java (मैं टाइमज़ोन के साथ टाइमस्टैम्प का उपयोग कर रहा था) में आपत्तिजनक लाइनें थीं:
else if (type == OffsetDateTime.class) {
result = (T) offsetDateTime(ctx.resultSet().getString(ctx.index()));
}
आप समय क्षेत्र न होने के आधार पर अन्य ifs की उस श्रृंखला में एक अलग लाइन पर हो सकते हैं।
अपने परीक्षण में, मैंने यह भी पाया कि सिस्टम समय बदलने से परिणाम बदल गया, लेकिन सत्र का समय बदलने से कुछ नहीं हुआ।
सौभाग्य से मेरे लिए, मानक पोस्टग्रेज ड्राइवर के लिए एक स्विच ने समस्या का समाधान किया। यदि ऐसा नहीं होता है, तो मैं toString के उपयोग को ठीक करने के लिए ऑफसेटडेटटाइम के लिए बाध्यकारी को ओवरलोड करने जा रहा था और यह प्रासंगिक समय क्षेत्र की स्ट्रिपिंग से जुड़ा हुआ है। दुर्भाग्य से, आपको उस पथ का अनुसरण करने की आवश्यकता हो सकती है, जब तक कि आप भी एक SQL ड्राइवर का उपयोग नहीं कर रहे हैं जिसे अपग्रेड या प्रतिस्थापित किया जा सकता है। या, आप इसे टाइमज़ोन के साथ स्टोर कर सकते हैं और जब आप डेटाबेस से लोड करते हैं तो वांछित टाइमज़ोन में कनवर्ट कर सकते हैं।
