JSON दिनांक प्रारूप "सही"

Question

मैंने JSON दिनांक प्रारूप के लिए कई अलग-अलग मानक देखे हैं:

"\"\\/Date(1335205592410)\\/\""         .NET JavaScriptSerializer
"\"\\/Date(1335205592410-0500)\\/\""    .NET DataContractJsonSerializer
"2012-04-23T18:25:43.511Z"              JavaScript built-in JSON object
"2012-04-21T18:25:43-05:00"             ISO 8601

कौन सा सही है? या सबसे अच्छा? क्या इस पर किसी तरह का मानक है?

Comments

JSON में कोई दिनांक प्रारूप नहीं है, केवल स्ट्रिंग एक de- / serializer है जो दिनांक मानों के लिए मैप करने का निर्णय लेता है।

strings, numbers, true, false, null, objectsऔरarrays

— रस कैम

हालाँकि, जावास्क्रिप्ट बिल्ट-इन JSON ऑब्जेक्ट और ISO8601 में मानव और कंप्यूटर द्वारा समझने की सभी जानकारी है और यह कंप्यूटर युग (1970-1-1) की शुरुआत पर निर्भर नहीं करता है।

— पोस्मा

Answer 1

JSON खुद निर्दिष्ट नहीं करता है कि तारीखों का प्रतिनिधित्व कैसे किया जाना चाहिए, लेकिन जावास्क्रिप्ट करता है।

आप चाहिए प्रारूप द्वारा उत्सर्जित का उपयोग Dateकी toJSONविधि:

2012-04-23T18:25:43.511Z

यहाँ पर क्यों:

1. यह मानव पठनीय है, लेकिन आत्मघाती भी है

2. यह सही ढंग से हल करता है

3. इसमें भिन्नात्मक सेकंड शामिल हैं, जो कालक्रम को फिर से स्थापित करने में मदद कर सकते हैं

4. यह आईएसओ 8601 के अनुरूप है

5. आईएसओ 8601 एक दशक से अधिक समय से अंतरराष्ट्रीय स्तर पर अच्छी तरह से स्थापित है

6. ISO 8601 W3C , RFC3339 और XKCD द्वारा समर्थित है

यह कहा जा रहा है , कभी भी लिखा गया हर पुस्तकालय "1970 से मिलीसेकंड" को समझ सकता है। तो आसान पोर्टेबिलिटी के लिए, ThiefMaster सही है।

Comments

ईसीएमए के अनुसार यह पसंदीदा अभ्यावेदन भी है :JSON.stringify({'now': new Date()}) "{"now":"2013-10-21T13:28:06.419Z"}"

— स्टीवन

मैं सूची में एक और महत्वपूर्ण कारण जोड़ूंगा: यह स्थानीय-स्वतंत्र है। यदि आपके पास 02-03-2014 जैसी तारीख थी, तो आपको यह जानने के लिए अतिरिक्त जानकारी की आवश्यकता होगी कि क्या यह 3 फरवरी या 2 मार्च को संदर्भित होता है। यह इस पर निर्भर करता है कि यूएस-प्रारूप या अन्य प्रारूप का उपयोग किया जाता है या नहीं।

— जुआनल

Xkcd का उल्लेख करने और जोड़ने के लिए upvote: D @ajorquera मैं आमतौर पर इसके लिए क्षणिका का उपयोग करता हूं। मैं भी इस संबंध में IE के साथ मुद्दों को देखा है

— fholzer

दूसरे बिंदु के बारे में, यह वर्ष 10000 के बाद सही ढंग से सॉर्ट नहीं करता है। हमारे पास हालांकि एक नए प्रारूप के साथ आने के लिए लगभग 8000 वर्ष हैं, इसलिए यह संभवतः एक मुद्दा नहीं है।

— एर्फा

दरअसल, @ इरा, चूंकि -अंकों से पहले आता है ASCII, यह वर्ष 100,000 तक ठीक रहेगा। ; पी

— बेन लेगिएरो

Answer 2

JSON को तारीखों के बारे में कुछ भी नहीं पता है। .NET क्या करता है एक गैर-मानक हैक / एक्सटेंशन है।

मैं एक प्रारूप का उपयोग करूंगा जिसे आसानी से Dateजावास्क्रिप्ट में किसी ऑब्जेक्ट में परिवर्तित किया जा सकता है , अर्थात जिसे पास किया जा सकता है new Date(...)। सबसे आसान और शायद सबसे पोर्टेबल प्रारूप 1970 से मिलीसेकंड युक्त टाइमस्टैम्प है।

Comments

stackoverflow.com/questions/10286385/… - चलो देखते हैं कि कोई जानता है कि एफएफ ऐसा क्यों व्यवहार करता है।

— ThiefMaster

यदि आप इस मार्ग पर जाते हैं, तो सुनिश्चित करें कि आपको 1970 से पहले की तारीखों से निपटने की आवश्यकता नहीं है!

— बेन डोलमैन

जैसा कि @BenDolman ने कहा, यह "समाधान" 1 जनवरी, 1970 (युग) से पहले की तारीखों के साथ उचित तरीके से नहीं है। इसके अलावा, एक कारण है कि ISO8601 पहले स्थान पर मौजूद है। यहां पृथ्वी पर हमारे पास "टाइम ज़ोन" नामक चीजें हैं। वह मिलीसेकंड में कहां है? JSON में दिनांक के लिए कोई मानक नहीं हो सकता है, लेकिन JSON के बाहर दिनांक मौजूद हैं, और उसके लिए एक मानक है। funroll का उत्तर सही है (यह भी देखें: xkcd.com/1179 )।

— जोनलक्स

शायद यह भी ध्यान देने योग्य है कि 1970 से (मिली) सेकंड भविष्य में तारीखों के लिए अनुमानित नहीं है क्योंकि हमारे पास छलांग सेकंड है । इसलिए मैं अंतर-प्रक्रिया संचार और डेटा भंडारण के लिए उपयोग नहीं करता। हालाँकि किसी प्रोग्राम में आंतरिक रूप से उपयोग करना अच्छा है क्योंकि इसे एक ही पूर्णांक में संग्रहीत किया जा सकता है जो आपको कुछ प्रदर्शन लाभ देता है।

— ब्रॉडी गार्नेट

यूनिक्स टाइमस्टैम्प हमेशा यूटीसी होता है, आप टाइमस्टैम्प उत्पन्न करने से पहले अपने स्थानीय टाइमज़ोन से परिवर्तित करते हैं, और प्रदर्शन पर स्थानीय टाइमज़ोन पर फिर से वापस जाते हैं, वहाँ कोई अस्पष्टता नहीं है।

— लैक्राइडर 15

Answer 3

कोई सही प्रारूप नहीं है ; JSON विनिर्देश दिनांकों जिसके कारण वहाँ यह करने के लिए बहुत से अलग तरीके हैं का आदान प्रदान के लिए एक प्रारूप निर्दिष्ट नहीं है।

सबसे अच्छा प्रारूप यकीनन आईएसओ 8601 प्रारूप ( विकिपीडिया देखें ) में दर्शाई गई तारीख है ; यह एक जाना-माना और व्यापक रूप से इस्तेमाल किया जाने वाला प्रारूप है और इसे कई अलग-अलग भाषाओं में संभाला जा सकता है, जिससे यह इंटरऑपरेबिलिटी के लिए बहुत अनुकूल है। यदि आपके पास उत्पन्न जेनसन पर नियंत्रण है, उदाहरण के लिए, आप जोंस प्रारूप में अन्य प्रणालियों को डेटा प्रदान करते हैं, तो 8601 का चयन करना क्योंकि तारीख इंटरचेंज प्रारूप एक अच्छा विकल्प है।

उदाहरण के लिए, यदि आपके पास जनरेट किए गए जोंस पर नियंत्रण नहीं है, तो आप कई अलग-अलग मौजूदा प्रणालियों के जोंस के उपभोक्ता हैं, इसे संभालने का सबसे अच्छा तरीका है कि विभिन्न स्वरूपों को संभालने के लिए डेट पार्सिंग यूटिलिटी फंक्शन होना चाहिए।

Comments

@mlissner लेकिन वह एक राय है जिस पर कोई सबसे अच्छा है। ISO-8601 एक मानक है, लेकिन यह JSON के लिए मानक नहीं है (भले ही मैं इसे इस्तेमाल करने के लिए इच्छुक हूं); उदाहरण के लिए, Microsoft ने इसका उपयोग नहीं करने का फैसला किया ( msdn.microsoft.com/en-us/library/… )। सबसे अच्छा अभ्यास एक (समझदार) सम्मेलन के साथ रहना है, जो कुछ भी है। जैसा कि मैंने उत्तर में कहा है, इसे संभालने का सबसे अच्छा तरीका एक तारीख पार्सिंग उपयोगिता फ़ंक्शन को परिभाषित करना है जो अपेक्षित स्वरूपों को संभाल सकता है। यदि आप विभिन्न स्वरूपों का उपयोग करने वाले सिस्टम के साथ एकीकृत करते हैं, तो फ़ंक्शन को प्रत्येक मामले को संभालना चाहिए।

— रस कैम

@RussCam, हम आगे और पीछे जा सकते हैं, लेकिन अगर कोई JSON में तारीखों को एन्कोड करने का सबसे अच्छा तरीका पूछ रहा है, तो वे पूछ रहे हैं कि जब वे JSON बनाते हैं तो तारीखों को प्रारूपित कैसे करें (और जवाब आमतौर पर ISO-8601 है)। आप विपरीत सवाल का जवाब दे रहे हैं: एक बार पहले से ही किए गए JSON दिनांक का उपभोग कैसे करें (हालांकि आपकी सलाह ध्वनि है)।

— mlissner

JSON स्कीमा विनिर्देश वास्तव में कहता है कि स्कीमा द्वारा सत्यापित तिथियां 8601 प्रारूप में होनी चाहिए।

— gnasher729

@ gnasher729 क्या आपके पास लिंक है?

— रस कैम

@vallismortis - पार्टियों के बीच बदले गए किसी दिए गए json संरचना के लिए स्कीमा को परिभाषित करने के लिए एक मसौदा विनिर्देश है, न कि json विनिर्देश में दिनांक के लिए प्रारूप। मैं अपने जवाब को टिप्पणियों के आधार पर संशोधित करने जा रहा हूं, ऐसा प्रतीत नहीं होता कि मैंने इसे पर्याप्त स्पष्ट कर दिया है

— Russ Cam

Answer 4

से आरएफसी 7493 (आई-JSON संदेश स्वरूप) :

I-JSON इंटरनेट JSON या इंटरऑपरेबल JSON के लिए खड़ा है, आप जो पूछते हैं उसके आधार पर।

प्रोटोकॉल में अक्सर डेटा आइटम होते हैं जिन्हें टाइमस्टैम्प या समय अवधि के लिए डिज़ाइन किया जाता है। यह सिफारिश की गई है कि इस तरह के सभी डेटा आइटम आईएसओ 8601 प्रारूप में स्ट्रिंग मान के रूप में व्यक्त किए जाते हैं, जैसा कि आरएफसी 3339 में निर्दिष्ट है , अतिरिक्त प्रतिबंधों के साथ कि लोअरकेस अक्षरों के बजाय अपरकेस का उपयोग किया जाए, जो कि टाइमज़ोन को डिफ़ॉल्ट रूप से शामिल नहीं किया जाना चाहिए, और वह वैकल्पिक अनुगामी सेकंड तब भी शामिल किया जाए जब उनका मूल्य "00" हो। यह भी तर्क दिया गया है कि समय अवधि वाले सभी डेटा आइटम RFC 3339 के परिशिष्ट A में "अवधि" उत्पादन के लिए समान अतिरिक्त प्रतिबंधों के साथ हैं।

Comments

यह वह प्रारूप भी है , जिसके द्वारा Date().toISOString()और समय Date().toJSON()सीमा Dateमान ट्रैक नहीं करता है, और इसलिए हमेशा UTC ( Z) समयक्षेत्र में टाइमस्टैम्प का उत्सर्जन करता है । मान का उपयोग करके पार्स किया जा सकता है new Date("...")और Date.parseDate।

— सोरेन लोर्बोर्ग

Answer 5

बस संदर्भ के लिए मैंने इस प्रारूप का उपयोग किया है:

Date.UTC(2017,2,22)

यह JSONP के साथ काम करता है जो फ़ंक्शन द्वारा समर्थित है $.getJSON()। मुझे यकीन नहीं है कि मैं इस दृष्टिकोण की सिफारिश करने के लिए इतनी दूर जाऊंगा ... बस इसे एक संभावना के रूप में वहां फेंक दूंगा क्योंकि लोग इस तरह से कर रहे हैं।

एफडब्ल्यूआईडब्ल्यू: संचार प्रोटोकॉल में युग के बाद से कभी भी सेकंड का उपयोग न करें, और न ही मिच के बाद से, क्योंकि ये लीप सेकंड के यादृच्छिक रूप से कार्यान्वयन के लिए खतरे से भरा होता है (आपको पता नहीं है कि प्रेषक और रिसीवर दोनों ठीक से यूएईपी लीप सेकंड को लागू करते हैं)।

एक पालतू जानवर से नफरत है, लेकिन कई लोगों का मानना ​​है कि UTC GMT का नया नाम है - गलत! यदि आपका सिस्टम लीप सेकंड को लागू नहीं करता है तो आप GMT (अक्सर गलत होने के बावजूद UTC कहलाते हैं) का उपयोग कर रहे हैं। यदि आप पूरी तरह से लीप सेकंड लागू करते हैं तो आप वास्तव में यूटीसी का उपयोग कर रहे हैं। भविष्य की छलांग सेकंड के लिए नहीं जानी जा सकती; वे आवश्यक रूप से IERS द्वारा प्रकाशित हो जाते हैं और निरंतर अपडेट की आवश्यकता होती है। यदि आप एक ऐसी प्रणाली चला रहे हैं जो लीप सेकंड को लागू करने का प्रयास करती है, लेकिन इसमें और बाहर की संदर्भ तालिका (जितना आप सोच सकते हैं) से अधिक सामान्य है, तो आपके पास न तो जीएमटी है, न ही यूटीसी, आपके पास यूटीसी होने का दिखावा करने वाला एक विजयी सिस्टम है।

ये दिनांक काउंटर केवल तब ही संगत होते हैं जब टूटे हुए प्रारूप (y, m, d, आदि) में व्यक्त किए जाते हैं। वे एक युग प्रारूप में संगत नहीं हैं। यह याद रखना।

Comments

मैं उस प्रारूप का उपयोग नहीं करूंगा, लेकिन आपके द्वारा प्रदान की गई बाकी जानकारी बहुत उपयोगी है, धन्यवाद!

— रॉबर्ट माइक्स

Answer 6

जब संदेह में बस F12 (फ़ायरफ़ॉक्स में Ctrl + K) दबाकर और एक आधुनिक ब्राउज़र के जावास्क्रिप्ट वेब कंसोल पर जाएं:

new Date().toISOString()

उत्पादन होगा:

"2019-07-04T13: 33: 03.969Z"

टा-दा !!

Answer 7

मेरा मानना ​​है कि सार्वभौमिक अंतर के लिए सबसे अच्छा प्रारूप ISO-8601 स्ट्रिंग नहीं है, बल्कि EJSON द्वारा उपयोग किया जाने वाला प्रारूप है:

{ "myDateField": { "$date" : <ms-since-epoch> } }

जैसा कि यहाँ बताया गया है: https://docs.meteor.com/api/ejson.html

लाभ

1. पार्सिंग प्रदर्शन: यदि आप तारीखों को ISO-8601 स्ट्रिंग्स के रूप में संग्रहीत करते हैं, तो यह बहुत अच्छा है यदि आप उस विशेष क्षेत्र के तहत दिनांक मान की अपेक्षा कर रहे हैं, लेकिन यदि आपके पास एक ऐसी प्रणाली है जो बिना संदर्भ के मूल्य प्रकार निर्धारित करना चाहिए, तो आप प्रत्येक स्ट्रिंग के लिए पार्स कर रहे हैं डेटा प्रारूप।
2. तिथि सत्यापन की कोई आवश्यकता नहीं: आपको तारीख के सत्यापन और सत्यापन के बारे में चिंता करने की आवश्यकता नहीं है। यहां तक ​​कि अगर एक स्ट्रिंग आईएसओ -8601 प्रारूप से मेल खाती है, तो यह एक वास्तविक तारीख नहीं हो सकती है; यह EJSON दिनांक के साथ कभी नहीं हो सकता।
3. असंदिग्ध प्रकार की घोषणा: जहाँ तक जेनेरिक डेटा सिस्टम जाते हैं, यदि आप एक मामले में एक स्ट्रिंग के रूप में एक आईएसओ स्ट्रिंग को स्टोर करना चाहते थे , और दूसरे में एक वास्तविक सिस्टम तिथि , ISO-8601 स्ट्रिंग प्रारूप को अपनाने वाले जेनेरिक सिस्टम इसे यांत्रिक रूप से अनुमति नहीं देंगे। (भागने की चाल या इसी तरह के भयानक समाधान के बिना)।

निष्कर्ष

मैं समझता हूं कि 80% उपयोग के मामलों के लिए मानव-पठनीय प्रारूप (ISO-8601 स्ट्रिंग) सहायक और अधिक सुविधाजनक है , और वास्तव में किसी को भी कभी भी अपनी तारीखों को ISO-8601 तार के रूप में संग्रहीत नहीं करने के लिए कहा जाना चाहिए यदि उनके आवेदन हैं समझ में आता है, लेकिन एक सार्वभौमिक रूप से स्वीकृत परिवहन प्रारूप के लिए जो निश्चित तारीखों के लिए कुछ मूल्यों की गारंटी चाहिए , हम अस्पष्टता की अनुमति कैसे दे सकते हैं और इतनी मान्यता की आवश्यकता है?

Comments

इस उत्तर को पहले धागे में देखें कि क्यों मिलीसेकंड के बाद से युगांतरों जैसे कि लीप सेकंड के गलत संगणना आदि हैं: stackoverflow.com/a/42480073/190476

— सुधांशु मिश्रा

@SudhanshuMishra आप जिन संदर्भों का उल्लेख करते हैं, वे यूनिक्स टाइमस्टैम्प की अत्यंत अकादमिक चिंताओं के लिए सामान्य आधार हैं, जो ज्यादातर टाइमस्टैम्प पीढ़ी से संबंधित हैं। यह मिलीसेकंड संकल्प के साथ एक चिंता का विषय भी कम है। जैसा कि एक अन्य टिप्पणी में कहा गया था, अधिकांश कंप्यूटर तिथियों को आंतरिक रूप से एक यूनिक्स टाइमस्टैम्प के रूप में दर्शाया जाता है, भले ही वे उजागर हों और अन्यथा स्वरूपित हों। फिर भी, किसी भी तारीख + समय के मिलीसेकंड प्रतिनिधित्व के साथ कुछ भी गलत नहीं है, खासकर जब अन्य दृष्टिकोणों के साथ तुलना की जाती है, जो हुड के नीचे समान नैनो-प्रभाव वाले कैविट्स द्वारा आसानी से प्रभावित हो सकता है।

— सिआब्रोस

यूनिक्स टाइमस्टैम्प के लिए "आउट ऑफ रेंज" तिथियों की चिंताओं को जोड़ने के लिए: वे सिस्टम स्टोरेज मुद्दे हैं, जिन्हें परिवहन प्रारूप की तुलना में बहुत व्यापक संदर्भ में संबोधित किया जाना है। उदाहरण के लिए, इस प्रारूप को 32 बिट में फिट होने वाले पूर्णांकों तक सीमित होने की आवश्यकता नहीं है, न ही इसे कड़ाई से सकारात्मक संख्याओं की आवश्यकता है, लेकिन कोई भी सिस्टम / आर्किटेक्चर स्तर पर टाइमस्टैम्प को गिराकर "वर्ष 2038 समस्या" को हल करने वाला नहीं है। ; उन्हें बस विस्तारित करने की आवश्यकता है (जैसे 64-बिट या उससे आगे), और यह इस प्रस्तावित परिवहन प्रारूप को प्रभावित नहीं करता है।

— सिआब्रोस

Answer 8

JSON में स्वयं कोई दिनांक प्रारूप नहीं है, यह परवाह नहीं करता है कि कोई भी दिनांक कैसे संग्रहीत करता है। हालाँकि, जब से इस प्रश्न को जावास्क्रिप्ट के साथ टैग किया गया है, मुझे लगता है कि आप जानना चाहते हैं कि जावास्क्रिप्ट में जावास्क्रिप्ट तिथियों को कैसे संग्रहीत किया जाए। आप बस JSON.stringifyविधि को एक तारीख में पास कर सकते हैं , और यह Date.prototype.toJSONडिफ़ॉल्ट रूप से उपयोग करेगा , जो मुड़ें का उपयोग करता है Date.prototype.toISOString( Date.to.com पर एमडीएन :

const json = JSON.stringify(new Date());
const parsed = JSON.parse(json); //2015-10-26T07:46:36.611Z
const date = new Date(parsed); // Back to date object

मुझे यह भी उपयोगी लगा कि जब भी मैं JSON के तार पढ़ता हूँ तो ISO स्ट्रिंग्स को javascript तारीखों में बदलने के लिए ( JSON.parse पर MDN ) के reviverपैरामीटर का उपयोग करना उपयोगी होता है ।JSON.parse

const isoDatePattern = new RegExp(/\d{4}-[01]\d-[0-3]\dT[0-2]\d:[0-5]\d:[0-5]\d\.\d+([+-][0-2]\d:[0-5]\d|Z)/);

const obj = {
 a: 'foo',
 b: new Date(1500000000000) // Fri Jul 14 2017, etc...
}
const json = JSON.stringify(obj);

// Convert back, use reviver function:
const parsed = JSON.parse(json, (key, value) => {
    if (typeof value === 'string' &&  value.match(isoDatePattern)){
        return new Date(value); // isostring, so cast to js date
    }
    return value; // leave any other value as-is
});
console.log(parsed.b); // // Fri Jul 14 2017, etc...

Answer 9

पसंदीदा तरीका उपयोग कर रहा है 2018-04-23T18:25:43.511Z...

नीचे दी गई तस्वीर बताती है कि यह पसंदीदा तरीका क्यों है:

तो जैसा कि आप देखते हैं कि दिनांक में एक मूल विधि है toJSON, जो returnइस प्रारूप में है और इसे Dateफिर से आसानी से परिवर्तित किया जा सकता है ...

Comments

सही बात! JSON डेटा इंटरचेंज सिंटैक्स मानक को निर्दिष्ट नहीं करता है: ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf लेकिन व्यवहार में, आईएसओ 8601 संगत प्रारूप जावास्क्रिप्ट रनटाइम सहित प्लेटफार्मों के लिए अधिक वांछनीय हैं।

— काम्येर नजीरी

Answer 10

Sharepoint 2013 में, JSON में डेटा मिलने से तारीख को केवल प्रारूप में बदलने का कोई प्रारूप नहीं है, क्योंकि उस तारीख में आईएसओ प्रारूप में होना चाहिए

yourDate.substring(0,10)

यह आपके लिए मददगार हो सकता है

Answer 11

"2014-01-01T23: 28: 56.782Z"

दिनांक को एक मानक और सॉर्ट करने योग्य प्रारूप में दर्शाया गया है जो UTC समय (Z द्वारा इंगित) का प्रतिनिधित्व करता है। ISO 8601, Z के साथ Z को बदलकर टाइम ज़ोन का समर्थन करता है + या - timezone ऑफसेट के लिए मान:

"2014-02-01T09: 28: 56.321-10: 00"

आईएसओ 8601 ऐनक में टाइमज़ोन एन्कोडिंग के अन्य रूपांतर हैं, लेकिन -10: 00 प्रारूप केवल टीएस प्रारूप है जो वर्तमान जेएसएन पार्सर्स समर्थन करते हैं। सामान्य तौर पर UTC आधारित प्रारूप (Z) का उपयोग करना सबसे अच्छा है जब तक कि आपको उस समय क्षेत्र का पता लगाने की कोई विशिष्ट आवश्यकता न हो जिसमें दिनांक का उत्पादन किया गया था (केवल सर्वर साइड पीढ़ी में संभव)।

NB: var date = new Date (); console.log (तारीख); // बुध जनवरी 01 2014 13:28:56 GMT- 1000 (हवाईयन मानक समय)

var json = JSON.stringify(date);
console.log(json);  // "2014-01-01T23:28:56.782Z"

आपको यह बताने के लिए कि जावास्क्रिप्ट इसके लिए एक मानक प्रारूप नहीं है, भले ही पसंदीदा तरीका है

// JSON encoded date
var json = "\"2014-01-01T23:28:56.782Z\"";

var dateStr = JSON.parse(json);  
console.log(dateStr); // 2014-01-01T23:28:56.782Z

Answer 12

अगर आप कोटलिन का इस्तेमाल कर रहे हैं तो इससे आपकी समस्या दूर हो जाएगी। (एमएस जसन प्रारूप)

val dataString = "/Date(1586583441106)/"
val date = Date(Long.parseLong(dataString.substring(6, dataString.length - 2)))

Answer 13

यह मेरे लिए पार्स सर्वर के साथ काम करता है

{
    "ContractID": "203-17-DC0101-00003-10011",
    "Supplier":"Sample Co., Ltd",
    "Value":12345.80,
    "Curency":"USD",
    "StartDate": {
                "__type": "Date",
                "iso": "2017-08-22T06:11:00.000Z"
            }
}

Answer 14

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

बाहर निकलने वाले बिट्स को स्ट्रिप करें और तारीखों को यूआई तक संख्याओं के रूप में मानें। आप प्रश्न और तर्क करने के लिए सरल अंकगणितीय ऑपरेटरों का उपयोग कर सकते हैं।

Comments

टिप्पणियों को चैट में स्थानांतरित कर दिया गया है ।

— जॉन क्लेमेंट्स

अब आपको 2 समस्याएं हैं: आपको कौन सा युग चुनना चाहिए, और आपको कौन सी मिलीसेकंड गिनना चाहिए? संभवतः सबसे आम विकल्प यूनिक्स समय है (1970-01-01T00: 00: 00 UTC और SI मिलीसेकंड को छोड़कर जो एक छलांग दूसरे के भीतर आते हैं), लेकिन निश्चित रूप से जो भविष्य के समय को अपरिभाषित बनाता है।

— अजा

तो आप माइक्रोसेकंड का प्रतिनिधित्व कैसे करते हैं? RFC3339 किसी भी सटीकता के साथ ठीक काम करता है, आपके पास एक पाठक होगा जो टाइमज़ोन को पार्स करता है और आपको सही समय की मोहर देता है, और अतिरिक्त जानकारी देता है। कैलेंडर ऐप्स आमतौर पर टाइम ज़ोन की परवाह करते हैं।

— gnasher729 17

Timezone यूआई चिंता का विषय नहीं है, जब तक आप अपनी अगली उड़ान को याद नहीं करते। उड़ानें स्थानीय समय में पोस्ट की जाती हैं और डीएसटी परिवर्तनों के लिए विशिष्ट नियमों का पालन करती हैं। ऑफ़सेट खो जाने का अर्थ है महत्वपूर्ण व्यावसायिक जानकारी को खोना

— पैनागोटिस कानावोस

कुछ और प्रतिवादों में 1970 से पहले के समय का प्रतिनिधित्व करने की क्षमता शामिल है (उस विशेष युग को मानते हुए), और JSONs की प्रवृत्ति कुछ हद तक मानव-पठनीय है।

— तिमो

Answer 15

निम्नलिखित कोड ने मेरे लिए काम किया है। यह कोड DD-MM-YYYY फॉर्मेट में प्रिंट होगा ।

DateValue=DateValue.substring(6,8)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(0,4);

वरना, आप भी उपयोग कर सकते हैं:

DateValue=DateValue.substring(0,4)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(6,8);

Answer 16

मुझे लगता है कि वास्तव में उपयोग के मामले पर निर्भर करता है। कई मामलों में एक उचित ऑब्जेक्ट मॉडल का उपयोग करना अधिक फायदेमंद हो सकता है (बजाय स्ट्रिंग को तिथि प्रदान करने के लिए), जैसे:

{
"person" :
      {
 "name" : {
   "first": "Tom",
   "middle": "M",
  ...
}
 "dob" :  {
         "year": 2012,
         "month": 4,
         "day": 23,
         "hour": 18,
         "minute": 25,
         "second": 43,
         "timeZone": "America/New_York"
    }   
   }
}

माना जाता है कि यह RFC 3339 से अधिक क्रिया है लेकिन:

• यह मानव पठनीय भी है
• यह एक उचित ऑब्जेक्ट मॉडल को लागू करता है (जैसे कि OOP, जहाँ तक JSON इसकी अनुमति देता है)
• यह समय क्षेत्र का समर्थन करता है (दी गई तारीख और समय पर केवल यूटीसी ऑफसेट नहीं)
• यह मिलीसेकंड, नैनोसेकंड, ... या बस आंशिक सेकंड जैसी छोटी इकाइयों का समर्थन कर सकता है
• इसके लिए एक अलग पार्सिंग स्टेप की आवश्यकता नहीं है (डेट-टाइम स्ट्रिंग को पार्स करने के लिए), JSON पार्सर आपके लिए सब कुछ करेगा
• किसी भी भाषा में किसी भी समय-समय की रूपरेखा या कार्यान्वयन के साथ आसान निर्माण
• आसानी से अन्य कैलेंडर तराजू (हिब्रू, चीनी, इस्लामी ...) और युगों (AD, BC, ...) का समर्थन करने के लिए बढ़ाया जा सकता है
• यह वर्ष 10000 सुरक्षित है ;-) (RFC 3339 नहीं है)
• पूरे दिन की तारीखों और अस्थायी समय का समर्थन करता है (जावास्क्रिप्ट की Date.toJSON()नहीं)

मुझे नहीं लगता कि सही छँटाई (जैसा कि RFC 3339 के लिए फ़नट्रोल द्वारा नोट किया गया है) एक ऐसी विशेषता है जिसकी JSON को तिथि निर्धारित करते समय वास्तव में आवश्यकता होती है। इसके अलावा, यह केवल उसी समय क्षेत्र ऑफ़सेट वाले दिनांक-समय के लिए सही है।

Comments

मुझे संदेह है कि किसी को भी वर्ष 10000 में json का उपयोग करना होगा, या उस समय तक भी 10000 वर्ष अभी भी वर्ष 10000 होगा। लेकिन यदि उन दोनों चीजें अभी भी सत्य हैं, तो प्रारूप को केवल 3 अंकों के लिए विस्तारित किया जा सकता है शताब्दी घटक। तो मैं कहूंगा कि लोग सुरक्षित रूप से RFC 3339 से चिपक सकते हैं, कम से कम वर्ष 9900 तक

— एक सपने की याद

@downvoters: मतदान महत्वपूर्ण क्यों है? यदि आप एक अगर downvote चाहिए post contains wrong information, is poorly researched, or fails to communicate information। कृपया बताएं कि इनमें से किन कारणों से आपने इस उत्तर को अस्वीकृत किया है।

— मार्टन

@Marten दो बातें। 1. आप पराजयों के लिए कभी भी स्पष्टीकरण नहीं दिया जाता है, हालांकि मैं समझता हूं कि यह मददगार हो सकता है। 2. मैंने आपके उत्तर को गलत नहीं ठहराया, लेकिन मुझे लगता है कि लोग आपके उत्तर को पसंद नहीं करते क्योंकि उन्हें लगता है कि ऐसा करने का यह गलत तरीका है। यह सवाल के रूप में "गलत जानकारी" के रूप में अर्हता प्राप्त करेगा क्योंकि सवाल कुछ करने के लिए सबसे अच्छा तरीका है

— केविन वेल्स

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

— आइज

@Phil, UTC वास्तव में एक समय क्षेत्र नहीं है (पृथ्वी पर ऐसा कोई स्थान नहीं है जो "UTC" को अपने आधिकारिक समय क्षेत्र के रूप में उपयोग करता है), यह एक समय मानक है । इसके अलावा समय क्षेत्र ऑफसेट काफी अप्रत्याशित हैं। यह कहने का कोई तरीका नहीं है कि क्या 2025 में "12:00 मास्को समय" अभी भी "9:00 UTC" है जैसे कि यह आज है, पिछले 30 वर्षों के दौरान इसे कुछ बार बदला गया है । यदि आप भविष्य के स्थानीय समय को व्यक्त करना चाहते हैं तो आपको सच्चे समय क्षेत्रों की आवश्यकता है।

— मार्टन