"ডান" JSON তারিখের ফর্ম্যাট


1137

আমি 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

কোনটি সঠিক? না সেরা? এটিতে কোনও ধরণের মান আছে?


75
জেএসএন-তে কোনও তারিখের বিন্যাস নেই, কেবলমাত্র একটি ডি-সিরিয়ালাইজ তারিখের মানগুলিতে মানচিত্রের সিদ্ধান্ত নেয় ings

11
strings, numbers, true, false, null, objectsএবংarrays
Russ ক্যাম

12
তবে জাভাস্ক্রিপ্ট অন্তর্নির্মিত জেএসওএন অবজেক্ট এবং আইএসও ৮8০১ এ মানব এবং কম্পিউটারের দ্বারা বোঝার জন্য সমস্ত তথ্য রয়েছে এবং কম্পিউটার যুগের শুরুতে (1970-1-1) নির্ভর করে না।
পাউসমা

উত্তর:


1847

কীভাবে তারিখগুলি উপস্থাপন করা উচিত তা JSON নিজেই নির্দিষ্ট করে না তবে জাভাস্ক্রিপ্টটি করে।

আপনি উচিত বিন্যাস দ্বারা নির্গত ব্যবহার Dateএর toJSONপদ্ধতি:

2012-04-23T18:25:43.511Z

কারণটা এখানে:

  1. এটি মানব পঠনযোগ্য তবে সংক্ষিপ্তকরণও

  2. এটি সঠিকভাবে সাজান

  3. এতে ভগ্নাংশের সেকেন্ড রয়েছে, যা কালানুক্রমকে পুনরায় প্রতিষ্ঠিত করতে সহায়তা করতে পারে

  4. এটি আইএসও 8601 অনুসারে

  5. আইএসও 8601 এক দশকেরও বেশি সময় ধরে আন্তর্জাতিকভাবে সু-প্রতিষ্ঠিত হয়েছে

  6. আইএসও 8601 দ্বারা অনুমোদিত W3C এর , RFC3339 এবং xkcd

বলা হয়ে থাকে যে , প্রতি লিখিত প্রতিটি তারিখের গ্রন্থাগার "1970 সাল থেকে মিলিসেকেন্ড" বুঝতে পারে। সহজ বহনযোগ্যতার জন্য, থিফমাস্টার সঠিক।


32
ইসিএমএ অনুসারে এটিও পছন্দের উপস্থাপনা :JSON.stringify({'now': new Date()}) "{"now":"2013-10-21T13:28:06.419Z"}"
স্টিভেন

11
আমি তালিকায় আরও একটি গুরুত্বপূর্ণ কারণ যুক্ত করব: এটি স্থানীয়-স্বতন্ত্র। আপনার যদি 02-03-2014 এর মতো তারিখ থাকে তবে এটি জানার জন্য আপনার অতিরিক্ত তথ্যের প্রয়োজন হবে এটি ফেব্রুয়ারীর 3 য় বা মার্চের 2 শে তারিখের বিষয়ে উল্লেখ করে কিনা। এটি ইউএস-ফর্ম্যাট বা অন্যান্য ফর্ম্যাট ব্যবহৃত হয় কিনা তার উপর নির্ভর করে।
জুয়ানাল

107
এক্সকেসিডি উল্লেখ এবং লিঙ্ক করার জন্য আপভোট: ডি @ অজর্কেরা আমি সাধারণত এর জন্য মুহুর্তগুলি ব্যবহার করি। আমি এই বিষয়ে আইই এর সাথে সমস্যাগুলিও দেখেছি
ফোলজার

54
দ্বিতীয় দফার বিষয়ে, এটি 10000 বছর পরে সঠিকভাবে বাছাই করা যায় না We যদিও আমাদের কাছে প্রায় 8000 বছর নতুন ফর্ম্যাট নিয়ে আসে, সুতরাং এটি সম্ভবত কোনও সমস্যা নয়।
এরফা

7
প্রকৃতপক্ষে, @ এরফা, যেহেতু অঙ্কগুলির -আগে আসবে ASCII, এটি 100,000 বছর অবধি ঠিক সাজবে । ; পি
বেন লেগিগেরো

128

জেএসএন তারিখ সম্পর্কে কিছুই জানে না। .NET কী করে তা হ'ল মানহীন হ্যাক / এক্সটেনশন।

আমি এমন একটি ফর্ম্যাট ব্যবহার করব যা Dateজাভাস্ক্রিপ্টে সহজে কোনও আইটেমে রূপান্তরিত হতে পারে , অর্থাত্ যেটিতে যেতে পারে new Date(...)। সবচেয়ে সহজ এবং সম্ভবত বহনযোগ্য বিন্যাসটি হ'ল 1970 সাল থেকে মিলিসেকেন্ড সমেত টাইমস্ট্যাম্প।


3
stackoverflow.com/questions/10286385/… - আসুন দেখে নেওয়া যাক কেউ এফএফের সাথে কেন এমন আচরণ করে।
চোরমাস্টার

11
আপনি যদি এই রুটে যান তবে নিশ্চিত হয়ে নিন যে আপনাকে 1970 এর আগে তারিখগুলির সাথে ডিল করার দরকার নেই!
বেন ডলম্যান

8
@ বেনডলম্যান যেমন বলেছিলেন, এই "সমাধান" 1 লা জানুয়ারী, 1970 (পূর্ববর্তী) এর পূর্বের তারিখগুলির সাথে যথাযথ আচরণ করে না। এছাড়াও, ISO8601 এর প্রথম স্থানে থাকার কারণ রয়েছে। এখানে পৃথিবীতে আমাদের কাছে "টাইম অঞ্চল" নামে জিনিস রয়েছে। মিলিসেকেন্ডে এটি কোথায়? জেএসএনের তারিখগুলির জন্য কোনও মানক নাও থাকতে পারে তবে তারিখগুলি জেএসএনের বাইরে রয়েছে এবং এর জন্য একটি মান আছে । ফানরোলের উত্তরটি সঠিক উত্তর (এটিও দেখুন: xkcd.com/1179 )।
জো লিনাক্স

5
এটা তোলে হয়তো এছাড়াও 1970 থেকে উল্লেখ যে (Milli) সেকেন্ড মূল্য কারণ আমরা আছে ভবিষ্যতে তারিখগুলি জন্য অনুমান করা যায় না লিপ সেকন্ড । সুতরাং আমি আন্তঃ-প্রক্রিয়া যোগাযোগ এবং ডেটা সঞ্চয় করার জন্য ব্যবহার করব না। কোনও প্রোগ্রামে অভ্যন্তরীণভাবে ব্যবহার করা ভাল তবে এটি একক পূর্ণসংখ্যায় সংরক্ষণ করা যেতে পারে যা আপনাকে কিছু কর্মক্ষমতা সুবিধা দেয়।
ব্রোডি গারনেট

5
ইউনিক্স টাইমস্ট্যাম্পটি সর্বদা ইউটিসি থাকে, আপনি টাইমস্ট্যাম্প তৈরির আগে আপনার স্থানীয় সময় অঞ্চল থেকে রূপান্তর করেন এবং প্রদর্শনীতে স্থানীয় টাইমজোনটিতে ফিরে যান, সেখানে কোনও দ্ব্যর্থতা নেই।
lkraider

46

সঠিক বিন্যাস নেই ; তাদেরকে JSON স্পেসিফিকেশন তারিখ হয় কেন এটা করতে অনেক বিভিন্ন উপায় আছে আদান প্রদানের জন্য একটি বিন্যাসে নির্দিষ্ট করে না।

সেরা ফর্ম্যাটটি যুক্তিযুক্তভাবে আইএসও 8601 ফর্ম্যাটে উপস্থাপনের একটি তারিখ ( উইকিপিডিয়া দেখুন ); এটি একটি সুপরিচিত এবং বহুল ব্যবহৃত ফর্ম্যাট এবং এটি ইন্টারঅ্যাপেরিবিলিটির জন্য খুব ভাল উপযোগী করে তোলে এবং এটি বিভিন্ন ভাষাতে পরিচালনা করা যায়। উত্পন্ন জসনের উপর যদি আপনার নিয়ন্ত্রণ থাকে, উদাহরণস্বরূপ, আপনি জসন ফর্ম্যাটে অন্যান্য সিস্টেমে ডেটা সরবরাহ করেন, 8601 তারিখের ইন্টারচেঞ্জ ফর্ম্যাট হিসাবে বেছে নেওয়া ভাল পছন্দ।

উত্পন্ন জসনের উপর যদি আপনার নিয়ন্ত্রণ না থাকে, উদাহরণস্বরূপ, আপনি বিভিন্ন বিদ্যমান সিস্টেম থেকে জসন এর গ্রাহক, এটি পরিচালনা করার সর্বোত্তম উপায়টি প্রত্যাশিত বিভিন্ন ফর্ম্যাটগুলি পরিচালনা করার জন্য একটি তারিখ পার্সিং ইউটিলিটি ফাংশন।


2
@ এমএমএসনার তবে এটি একটি মতামত যা সবচেয়ে ভাল। ISO-8601 একটি মান, তবে এটি JSON এর জন্য মান নয় (যদিও আমি এটি ব্যবহারে আগ্রহী হব); উদাহরণস্বরূপ, মাইক্রোসফ্ট এটিকে ব্যবহার না করার সিদ্ধান্ত নিয়েছে ( এমএসডিএন.মাইক্রোসফট . / ম- মাইক্রোসফট / en-us / library/… )। সর্বোত্তম অনুশীলন হ'ল একটি (বোধগম্য) কনভেনশন, যা কিছু হোক না কেন with আমি উত্তরে যেমন বলেছি, এটি পরিচালনা করার সর্বোত্তম উপায় হ'ল একটি তারিখ পার্সিং ইউটিলিটি ফাংশন যা প্রত্যাশিত বিন্যাসগুলি পরিচালনা করতে পারে। আপনি যদি বিভিন্ন ফর্ম্যাট ব্যবহার করে এমন সিস্টেমে সংহত হন তবে ফাংশনটি প্রতিটি কেস পরিচালনা করবে।
রুশ ক্যাম

1
@ রাসক্যাম, আমরা পিছনে পিছনে যেতে পারি, তবে যদি কেউ জেএসএনে তারিখগুলি এনকোড করার সর্বোত্তম উপায় জিজ্ঞাসা করছে, তারা জেএসএন তৈরি করার সময় তারিখগুলি কীভাবে বিন্যাস করবেন তা জিজ্ঞাসা করছেন (এবং উত্তরটি সাধারণত আইএসও -8601)। আপনি বিপরীত প্রশ্নের উত্তর দিচ্ছেন: জেএসএন তারিখগুলি ইতিমধ্যে তৈরি হয়ে গেলে কীভাবে সেবন করবেন (যদিও আপনার পরামর্শটি যথাযথ)।
mlissner

1
জেএসএন স্কিমা স্পেসিফিকেশন আসলে বলেছে যে স্কিমা দ্বারা যাচাই করা তারিখগুলি অবশ্যই 8601 ফর্ম্যাটে থাকতে হবে।
gnasher729

3
@ gnasher729 আপনার কি লিঙ্ক আছে?
রাশ ক্যাম

@ ওয়ালিজমর্টিস - এটি দলগুলির মধ্যে বিনিময় প্রদত্ত জসন কাঠামোর জন্য স্কিমা সংজ্ঞা দেওয়ার জন্য একটি খসড়া স্পেসিফিকেশন, জসন স্পেসিফিকেশনের তারিখের বিন্যাস নয় not আমি মন্তব্যের উপর ভিত্তি করে আমার উত্তরটি সংশোধন করতে যাচ্ছি, এটি প্রদর্শিত হচ্ছে না আমি এটি যথেষ্ট পরিষ্কার করে দিয়েছি
রাশ ক্যাম

27

আরএফসি থেকে 7493 (আই-জেএসএন বার্তা ফর্ম্যাট) :

আই-জেএসএন হ'ল ইন্টারনেট জেএসওএন বা ইন্টারঅ্যাপেবল জেএসওএন, আপনি কাকে জিজ্ঞাসা করে তার উপর নির্ভর করে।

প্রোটোকলগুলিতে প্রায়শই ডেটা আইটেম থাকে যা টাইমস্ট্যাম্প বা সময়কাল অন্তর্ভুক্ত করার জন্য ডিজাইন করা হয়। এটি সুপারিশ করা হয় যে এই জাতীয় সমস্ত আইটেম আইএসও 8601 ফর্ম্যাটে স্ট্রিং মান হিসাবে প্রকাশ করা হবে, আরএফসি 3339-তে উল্লিখিত হিসাবে , ছোট ছোট অক্ষরগুলির চেয়ে বড় হাতের অক্ষর ব্যবহারের অতিরিক্ত বিধিনিষেধের সাথে টাইমজোনটি ডিফল্ট না হয়ে অন্তর্ভুক্ত করা হবে এবং সেই বিকল্প alচ্ছিক সেকেন্ড তাদের মান "00" হলেও অন্তর্ভুক্ত করুন। এটিও সুপারিশ করা হয় যে সময়ের অতিরিক্ত সময়সীমাযুক্ত সমস্ত ডেটা আইটেম একই অতিরিক্ত বিধিনিষেধের সাথে আরএফসি 3339 এর পরিশিষ্ট এ "সময়কাল" উত্পাদনের সাথে সঙ্গতিপূর্ণ।


2
এটি টাইমজোন মান ট্র্যাক করে না এমন সীমাবদ্ধতার সাথে Date().toISOString()এবং এটি উত্পাদিত ফর্ম্যাটও এবং তাই সর্বদা ইউটিসি ( ) টাইমজোনটিতে টাইমস্ট্যাম্পগুলি নির্গত করে । মানটি ব্যবহার করে এবং পার্স করা যায় । Date().toJSON()DateZnew Date("...")Date.parseDate
সেরেন ল্যাভবার্গ

15

কেবল রেফারেন্সের জন্য আমি এই ফর্ম্যাটটি ব্যবহার করেছি:

Date.UTC(2017,2,22)

এটি JSONP- এর সাথে কাজ করে যা $.getJSON()ফাংশন দ্বারা সমর্থিত । নিশ্চিত নই যে আমি এই পদ্ধতির সুপারিশ করার জন্য এতদূর যাব ... সম্ভাবনা হিসাবে এটি কেবল সেখানে ফেলে দিচ্ছি কারণ লোকেরা এইভাবে এটি করছে।

FWIW: কোনও যোগাযোগ প্রোটোকলে পর্বের আগে কখনও সেকেন্ড ব্যবহার করবেন না, বা মহাকাল থেকে মিলিসেকেন্ডগুলি কখনও ব্যবহার করবেন না, কারণ এগুলি লিপ সেকেন্ডের এলোমেলোভাবে প্রয়োগের জন্য বিপদজনক কারণে পূর্ণ (প্রেরক এবং রিসিভার উভয়ই ইউটিসি লিপ সেকেন্ড প্রয়োগ করে কিনা তা আপনার কোনও ধারণা নেই)।

পোষা প্রাণীর ঘৃণা, তবে অনেকে বিশ্বাস করেন যে ইউটিসি হ'ল জিএমটি-র নতুন নাম - ভুল! যদি আপনার সিস্টেমটি লিপ সেকেন্ড কার্যকর না করে তবে আপনি জিএমটি ব্যবহার করছেন (প্রায়শই ভুল হয়েও ইউটিসি নামে পরিচিত)। আপনি যদি পুরোপুরি লিপ সেকেন্ড প্রয়োগ করেন তবে আপনি সত্যই ইউটিসি ব্যবহার করছেন। ভবিষ্যতের লিপ সেকেন্ডগুলি জানা যায় না; এগুলি আইআরএস দ্বারা প্রয়োজনীয় হিসাবে প্রকাশিত হয় এবং ধ্রুবক আপডেটের প্রয়োজন হয়। আপনি যদি এমন একটি সিস্টেম চালাচ্ছেন যা লিপ সেকেন্ড বাস্তবায়নের চেষ্টা করে তবে এতে রয়েছে এবং মেয়াদোত্তীর্ণ রেফারেন্স টেবিল রয়েছে (আপনার মনে হতে পারে তার চেয়ে বেশি সাধারণ) তবে আপনার জিএমটি বা ইউটিসি নেই, আপনার ইউটিসি হওয়ার ভান করার মতো একটি উইকি সিস্টেম রয়েছে।

এই তারিখের কাউন্টারগুলি কেবল তখনই সামঞ্জস্যপূর্ণ যখন একটি ভাঙ্গা ডাউন ফর্ম্যাট (y, m, d, ইত্যাদিতে) প্রকাশ করা হয়। এরা কোন যুগের বিন্যাসে সামঞ্জস্যপূর্ণ নয়। মন যে রাখতে.


4
আমি সেই ফর্ম্যাটটি ব্যবহার করব না, তবে আপনার প্রদত্ত তথ্যটি খুব দরকারী, আপনাকে ধন্যবাদ!
রবার্ট মাইকস

9

সন্দেহ হলে কেবল এফ 12 (ফায়ারফক্সে Ctrl + K) টিপে একটি আধুনিক ব্রাউজারের জাভাস্ক্রিপ্ট ওয়েব কনসোলে যান এবং নিম্নলিখিতগুলি লিখুন:

new Date().toISOString()

আউটপুট দেবে:

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

Ta-দা !!


3

আমি বিশ্বাস করি যে সর্বজনীন আন্তঃব্যবহারের জন্য সর্বোত্তম বিন্যাসটি আইএসও -8601 স্ট্রিং নয়, বরং ইজেএসন দ্বারা ব্যবহৃত ফর্ম্যাট:

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

এখানে বর্ণিত হিসাবে: https://docs.meteor.com/api/ejson.html

উপকারিতা

  1. পার্সিং পারফরম্যান্স: আপনি যদি ISO-8601 স্ট্রিং হিসাবে তারিখগুলি সঞ্চয় করেন তবে আপনি যদি সেই নির্দিষ্ট ক্ষেত্রের অধীনে একটি তারিখের মান আশা করেন তবে এটি দুর্দান্ত, তবে আপনার যদি এমন একটি সিস্টেম থাকে যা প্রসঙ্গ ছাড়াই মানের ধরণগুলি নির্ধারণ করতে পারে তবে আপনি প্রতিটি স্ট্রিং একটি জন্য পার্স করছেন তারিখ বিন্যাস.
  2. তারিখ বৈধকরণের প্রয়োজন নেই : আপনার তারিখের বৈধতা এবং যাচাইকরণ সম্পর্কে চিন্তা করার দরকার নেই। এমনকি যদি কোনও স্ট্রিং আইএসও -8601 ফর্ম্যাটের সাথে মেলে তবে এটি আসল তারিখ হতে পারে না; এটি কোনও ইজেসন তারিখের সাথে কখনই ঘটতে পারে না।
  3. দ্ব্যর্থহীন প্রকারের ঘোষণাপত্র: জেনেরিক ডেটা সিস্টেমগুলি যতদূর যায়, যদি আপনি কোনও ক্ষেত্রে স্ট্রিং হিসাবে কোনও আইএসও স্ট্রিং সংরক্ষণ করতে চান এবং অন্যটিতে একটি সত্যিকারের তারিখ থাকে, তবে জেনেরিক সিস্টেমগুলি আইএসও -8601 স্ট্রিং ফর্ম্যাটটি গ্রহণ করবে না, যান্ত্রিকভাবে (পালানোর কৌশল বা অনুরূপ ভয়াবহ সমাধান ছাড়াই)।

উপসংহার

আমি বুঝতে পেরেছি যে 80% ব্যবহারের ক্ষেত্রে মানব-পঠনযোগ্য ফর্ম্যাট (ISO-8601 স্ট্রিং) সহায়ক এবং আরও সুবিধাজনক , এবং সত্যই কারও কাছেই বলা উচিত নয় যে তারা তাদের তারিখগুলি আইএসও -8601 স্ট্রিং হিসাবে সংরক্ষণ করবে না যদি এটি তাদের অ্যাপ্লিকেশনগুলির হয় বুঝি, কিন্তু একটি সার্বজনীনভাবে স্বীকৃত পরিবহন বিন্যাস যা নির্দিষ্ট মান গ্যারান্টি উচিত নিশ্চিত তারিখ হতে, কিভাবে আমরা অস্পষ্টতা এবং আরও অনেক বৈধতা প্রয়োজনীয়তার জন্য অনুমতি পারি?


যুগে যুগে যুগে যুগে লিপ সেকেন্ডের ভুল গণনা ইত্যাদির জন্য কেন এই জাতীয় উত্তর আগে থ্রেডে এই উত্তরটি দেখুন: স্ট্যাকওভারফ্লো.com
42480073

@ সুধাংশু মিশ্রা আপনার যে রেফারেন্সটি উল্লেখ করেছেন তা হ'ল ইউনিক্স টাইমস্ট্যাম্পগুলির চূড়ান্ত একাডেমিক উদ্বেগের জন্য বেশিরভাগ টাইমস্ট্যাম্প প্রজন্মের সাথে সম্পর্কিত got এটি মিলিসেকেন্ড রেজোলিউশনের সাথেও উদ্বেগের চেয়ে কম। অন্য মন্তব্যে যেমন ডাকা হয়েছিল, বেশিরভাগ কম্পিউটারের তারিখগুলি অভ্যন্তরীণভাবে ইউনিক্স টাইমস্ট্যাম্প হিসাবে উপস্থাপিত হয়, এমনকি যদি তা অন্যথায় প্রকাশ করা হয় এবং ফর্ম্যাট করা হয়। তবুও, কোনও নির্দিষ্ট তারিখ + সময়কে মিলিসেকেন্ড উপস্থাপনের ক্ষেত্রে কোনও ভুল নেই, বিশেষত যখন অন্যান্য পদ্ধতির সাথে তুলনা করা হয় যা হুডের নীচে একই ন্যানো-ইফেক্ট ক্যাভ্যাট দ্বারা সহজেই প্রভাবিত হতে পারে।
Ciabaros

ইউনিক্স টাইমস্ট্যাম্পগুলির জন্য "সীমার বাইরে" তারিখগুলির উদ্বেগের বিষয়ে কেবল যুক্ত করার জন্য: সেগুলি হ'ল সিস্টেম স্টোরেজ সমস্যা, পরিবহণের বিন্যাসের চেয়ে আরও বিস্তৃত প্রসঙ্গে সম্বোধন করা। উদাহরণস্বরূপ, এই ফর্ম্যাটটি 32 বিটগুলির মধ্যে ফিট করে এমন পূর্ণসংখ্যার মধ্যে সীমাবদ্ধ হওয়ার দরকার নেই, তেমনি এটি কঠোরভাবে ইতিবাচক সংখ্যাও হওয়া দরকার না, তবে কেউ সিস্টেম / আর্কিটেকচার স্তরে টাইমস্ট্যাম্পগুলি ফেলে "বছর 2038 সমস্যা" সমাধান করতে যাচ্ছেন না ; এগুলি কেবল প্রসারিত করা দরকার (উদাহরণস্বরূপ -৪-বিট বা তার বেশি), এবং এটি প্রস্তাবিত পরিবহন বিন্যাসকে প্রভাবিত করে না।
Ciabaros

3

জেএসএনের নিজেই কোনও তারিখের বিন্যাস নেই, এটি কীভাবে কেউ খেজুর সঞ্চয় করে তা বিবেচ্য নয়। তবে, যেহেতু এই প্রশ্নটি জাভাস্ক্রিপ্টের সাথে ট্যাগ করা হয়েছে, আমি ধরে নিয়েছি আপনি JSON এ জাভাস্ক্রিপ্টের তারিখগুলি কীভাবে সংরক্ষণ করবেন তা জানতে চান। আপনি কেবল JSON.stringifyপদ্ধতিতে একটি তারিখে পাস করতে পারেন , এবং এটি Date.prototype.toJSONডিফল্টরূপে ব্যবহার করবে , যা ঘুরিয়ে ব্যবহার করে Date.prototype.toISOString( তারিখ. টোএসএসে MDN ):

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 স্ট্রিংগুলি পড়ি তখন জাভাস্ক্রিপ্টের তারিখগুলিতে স্বয়ংক্রিয়ভাবে আইএসএস স্ট্রিংগুলিকে জাভাস্ক্রিপ্টের তারিখগুলিতে রূপান্তর করতে ( 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...

2

পছন্দের উপায়টি ব্যবহার করা হচ্ছে 2018-04-23T18:25:43.511Z...

নীচের চিত্রটিতে দেখানো হয়েছে যে এটি কেন পছন্দের উপায়:

জেএসএন তারিখ

আপনি যেমন দেখতে পান তারিখের একটি দেশীয় পদ্ধতি রয়েছে toJSONযা returnএই ফর্ম্যাটে এবং সহজেই Dateআবার রূপান্তর করা যায় ...


2
সঠিক! JSON ডেটা ইন্টারচেঞ্জ সিনট্যাক্সটি স্ট্যান্ডার্ডটি নির্দিষ্ট করে না: ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf কিন্তু বাস্তবে , আইএসও 8601 সামঞ্জস্যপূর্ণ ফর্ম্যাটগুলি জাভাস্ক্রিপ্ট রানটাইম সহ প্ল্যাটফর্মগুলিতে আরও আকাঙ্ক্ষিত।
কামায়ার নাজেরী

1

শেয়ারপয়েন্ট 2013 এ, জেএসএন-তে ডেটা পাওয়া কেবলমাত্র তারিখকে কেবলমাত্র ফর্ম্যাটে রূপান্তর করার জন্য কোনও বিন্যাস নেই, কারণ সেই তারিখে আইএসও ফর্ম্যাটে থাকতে হবে

yourDate.substring(0,10)

এটি আপনার পক্ষে সহায়ক হতে পারে


0

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

তারিখটি একটি স্ট্যান্ডার্ড এবং সাজানোর যোগ্য বিন্যাসে উপস্থাপিত হয় যা কোনও ইউটিসি সময়কে উপস্থাপন করে (জেড দ্বারা নির্দেশিত)। আইএসও 8601 টাইমজোন অফসেটের জন্য জেডকে + বা - মান দিয়ে প্রতিস্থাপন করে সময় অঞ্চলগুলি সমর্থন করে:

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

আইএসও 8601 স্পিকে টাইমজোন এনকোডিংয়ের অন্যান্য বিভিন্নতা রয়েছে, তবে J10: 00 ফর্ম্যাটটি হ'ল একমাত্র টিজেড ফর্ম্যাট যা বর্তমান জেএসএন পার্সার সমর্থন করে। সাধারণভাবে ইউটিসি ভিত্তিক ফর্ম্যাট (জেড) ব্যবহার করা সবচেয়ে ভাল তবে যদি আপনার তারিখটি নির্ধারিত সময় অঞ্চলটি নির্ধারণের জন্য নির্দিষ্ট প্রয়োজন না হয় (কেবলমাত্র সার্ভার সাইড জেনারেশনেই সম্ভব)।

এনবি: বর্ণের তারিখ = নতুন তারিখ (); 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

0

আপনি যদি কোটলিন ব্যবহার করছেন তবে এটি আপনার সমস্যার সমাধান করবে। (এমএস জসন ফর্ম্যাট)

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

-3

এটি পার্স সার্ভারের সাথে আমার কাজ

{
    "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"
            }
}

-6

এটির জন্য কেবল একটি সঠিক উত্তর রয়েছে এবং বেশিরভাগ সিস্টেমে এটি ভুল হয়ে যায়। যুগের পর থেকে মিলিসেকেন্ডের সংখ্যা, একটি bit৪ বিট পূর্ণসংখ্যা। সময় অঞ্চলটি একটি ইউআই উদ্বেগ এবং অ্যাপ্লিকেশন স্তর বা ডিবি স্তরতে কোনও ব্যবসা নেই। আপনার ডিবি কেন সময় জোন কোনটি যত্ন করে না, যখন আপনি জানেন যে এটি একটি 64 বিট পূর্ণসংখ্যা হিসাবে সংরক্ষণ করবে তখন রূপান্তর গণনা করুন do

বহিরাগত বিটগুলি ছড়িয়ে দিন এবং কেবলমাত্র তারিখগুলি ইউআই পর্যন্ত গণ্য করুন। আপনি কোয়েরি এবং লজিক করতে সাধারণ গাণিতিক অপারেটরগুলি ব্যবহার করতে পারেন।


মন্তব্যগুলি চ্যাটে সরানো হয়েছে ।
জন ক্লিমেটস

5
এখন আপনার 2 টি সমস্যা রয়েছে: আপনি কোন যুগকে বেছে নেবেন এবং কোন মিলি সেকেন্ড আপনার গণনা করা উচিত? সম্ভবত সর্বাধিক সাধারণ পছন্দটি ইউনিক্স সময় (1970-01-01T00: 00: 00 ইউটিসি এবং এসআই মিলিসেকেন্ডগুলি যা একটি লিপ সেকেন্ডের মধ্যে পড়ে তাদের ব্যতীত) তবে অবশ্যই ভবিষ্যতের সময়গুলি অপরিজ্ঞাত করে তোলে।
এআইজ

2
তাহলে আপনি মাইক্রোসেকেন্ডগুলিকে কীভাবে উপস্থাপন করবেন? আরএফসি 3339 যে কোনও নির্ভুলতার সাথে সূক্ষ্মভাবে কাজ করে, আপনার কাছে এমন একটি পাঠক থাকবে যা টাইমজোনটিকে পার্স করে এবং আপনাকে সঠিক সময় স্ট্যাম্প দেয় এবং এটি অতিরিক্ত তথ্য। ক্যালেন্ডার অ্যাপ্লিকেশনগুলি সাধারণত সময় অঞ্চলগুলির যত্ন করে।
gnasher729

11
টাইমজোন কোনও ইউআই উদ্বেগ নয়, যদি না আপনি নিজের পরবর্তী ফ্লাইটটি মিস করার কথা মনে করেন। স্থানীয় সময় ফ্লাইটগুলি পোস্ট করা হয় এবং ডিএসটি পরিবর্তনের জন্য নির্দিষ্ট নিয়ম অনুসরণ করে। অফসেট হারানো মানে গুরুত্বপূর্ণ ব্যবসায়ের তথ্য হারাতে হবে
পানাগিওটিস কানভোস

1
আরও কিছু পাল্টা পরামর্শগুলির মধ্যে রয়েছে 1970 এর আগে সময়ের প্রতিনিধিত্ব করার ক্ষমতা (সেই নির্দিষ্ট যুগকে ধরে নেওয়া) এবং জেএসওএনগুলির প্রবণতা কিছুটা মানব-পঠনযোগ্য হওয়ার অন্তর্ভুক্ত।
টিমো

-8

নিম্নলিখিত কোডটি আমার পক্ষে কাজ করেছে। এই কোডটি 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);

-19

আমি মনে করি এটি সত্যিই ব্যবহারের ক্ষেত্রে নির্ভর করে। বেশিরভাগ ক্ষেত্রে এটি যথাযথ অবজেক্ট মডেল (তারিখটিকে স্ট্রিংয়ের পরিবর্তে পরিবর্তিত করার পরিবর্তে) ব্যবহার করা আরও সুবিধাজনক হতে পারে:

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

স্বীকার করা যায় যে এটি আরএফসি 3339 এর চেয়ে বেশি ভার্বোস তবে:

  • এটি মানব পঠনযোগ্যও
  • এটি একটি উপযুক্ত অবজেক্ট মডেল প্রয়োগ করে (ওওপি তে যেমন জেএসওএন এটির অনুমতি দেয়)
  • এটি সময় অঞ্চলগুলিকে সমর্থন করে (কেবলমাত্র ইউটিসি প্রদত্ত তারিখ এবং সময়ে অফসেট নয়)
  • এটি মিলিসেকেন্ড, ন্যানোসেকেন্ডস, ... বা কেবল ভগ্নাংশের সেকেন্ডের মতো ছোট ইউনিটগুলিকে সমর্থন করতে পারে
  • এটির জন্য আলাদা পার্সিং পদক্ষেপের প্রয়োজন নেই (তারিখের সময়ের স্ট্রিংটি পার্স করার জন্য), জেএসএন পার্সার আপনার জন্য সবকিছু করবে
  • যে কোনও ভাষায় তারিখ-সময় কাঠামো বা প্রয়োগের সাথে সহজ সৃষ্টি
  • অন্যান্য ক্যালেন্ডার স্কেল (হিব্রু, চীনা, ইসলামিক ...) এবং যুগ (AD, খ্রিস্টপূর্ব, ...) সমর্থন করার জন্য সহজেই বাড়ানো যেতে পারে can
  • এটি 10000 বছর নিরাপদ ;-) (আরএফসি 3339 নয়)
  • সারাদিনের তারিখ এবং ভাসমান সময়গুলি সমর্থন করে (জাভাস্ক্রিপ্টের Date.toJSON()নেই)

আমি মনে করি না যে সঠিক বাছাই (আরএফসি 3339 এর জন্য ফ্যানরোল দ্বারা উল্লিখিত) এমন একটি বৈশিষ্ট্য যা জেএসএন-তে কোনও তারিখ সিরিয়াল করার সময় সত্যই প্রয়োজন। একই তারিখের সময় একই জোন অফসেট থাকার ক্ষেত্রে এটি কেবল সত্য।


7
আমি সন্দেহ করি যে কেউ 10000 বর্ষে জসন ব্যবহার করবে, বা এমনকি সেই সময়ের মধ্যেও 10000 বছরটি 10000 বছর হবে But তবে যদি এখনও এই দুটি জিনিস সত্য হয়, তবে ফর্ম্যাটটি কেবল 3 ডিজিটের সাথে বাড়ানো যেতে পারে শতাব্দী উপাদান। সুতরাং আমি বলতে চাই যে লোকেরা কমপক্ষে 9900 সাল পর্যন্ত নিরাপদে আরএফসি 3339 দিয়ে আটকে থাকতে পারে
একটি স্বপ্নের স্মৃতি

8
@ ডাউনভোটার্স: মতে কেন ভোটদান গুরুত্বপূর্ণ? আপনি যদি একটি যদি downvote উচিত post contains wrong information, is poorly researched, or fails to communicate information। দয়া করে ব্যাখ্যা করুন যে এইগুলির মধ্যে কোন একটি কারণে আপনি এই উত্তরটিকে নীচে নামিয়ে দিয়েছেন।
মার্টেন

5
@ মার্টেন দুটি জিনিস। ১. আপনি কখনই ডাউনভোটদের ব্যাখ্যা ব্যাখ্যা পাচ্ছেন না, যদিও আমি বুঝতে পারি এটি সহায়ক হতে পারে। ২. আমি আপনার উত্তরটিকে নিম্নচলিত করি নি, তবে আমি অনুমান করব যে লোকেরা আপনার উত্তর পছন্দ করে না কারণ তারা মনে করে এটি এটি করার জন্য ভুল উপায়। যেহেতু এটি "ভুল তথ্য" হিসাবে যোগ্যতা অর্জন করবে যেহেতু প্রশ্নটি কিছু করার সর্বোত্তম উপায় অনুসন্ধান করছে
কেভিন ওয়েলস

7
আমি আপনাকে হ্রাস করি নি, তবে আমি অবশ্যই বুঝতে পারি যে "কীভাবে" অন্য একটি সুনির্দিষ্টভাবে নির্দিষ্ট ফর্ম্যাটটি আবিষ্কার করা হয়েছে "(যা মূলত আপনি যা বলছেন) ভুল বা খারাপ গবেষণা হিসাবে দেখা হবে।
এজ

2
@ ফিল, ইউটিসি সত্যই কোনও সময় অঞ্চল নয় (পৃথিবীতে এমন কোনও স্থান নেই যা "ইউটিসি" এর অফিসিয়াল সময় অঞ্চল হিসাবে ব্যবহার করে), এটি একটি সময়ের মান । এছাড়াও টাইম জোনের অফসেটগুলি বেশ অনাকাঙ্ক্ষিত। 2025 "12:00 মস্কোর সময়" এখনও "9:00 ইউটিসি" এর মতো থাকলেও গত 30 বছরে কয়েকবার পাল্টানো হয়েছে কিনা তা বলার উপায় নেই । আপনি যদি ভবিষ্যতের স্থানীয় সময়টি প্রকাশ করতে চান তবে আপনার সত্যিকারের সময় অঞ্চল প্রয়োজন।
মার্টেন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.