JSON-এ টাইমস্ট্যাম্পের ফরম্যাট কী
সংক্ষেপে: Epoch সংখ্যা আর ISO স্ট্রিং — প্রতিটির সমঝোতা আছে, কিন্তু সেগুলো মেশানোই আসল ক্ষতি করে। অফসেটসহ ISO 8601 ব্যবহার করুন, UTC-তে সংরক্ষণ করুন, ব্যবহারকারীর টাইম জোনে দেখান।
মূল কথা: তারে স্পষ্ট অফসেটসহ ISO 8601 ব্যবহার করুন, Z-এ শেষ হওয়া UTC সংরক্ষণ করুন, আর কেবল প্রদর্শনের সময় রূপান্তর করুন; epoch সংখ্যা বাছলে সেকেন্ড বনাম মিলিসেকেন্ড সর্বত্র স্থির করুন আর একক ফিল্ড-নামে রাখুন।
2026-10-30 14:30:00 যথেষ্ট নয় কেন
এই স্ট্রিং কোনো জোন বহন করে না। সাংহাইয়ের ১৪:৩০ আর লন্ডনের ১৪:৩০ আট ঘণ্টা দূরে, আর কোনটি বোঝানো হয়েছে বলার উপায় নেই। new Date('2026-10-30 14:30:00') রানটাইমের লোকাল জোনে পার্স করে, তাই সার্ভার ও ব্রাউজার এক পেললোড থেকে দুই ভিন্ন সময়বিন্দু পায় — এমন বাগ যা কখনো পুনরুৎপাদন হয় না।
খালি 2026-10-30 আদৌ সময়বিন্দু নয়। জন্মদিন ও বিলিং সময়কালে ঠিক, সৃষ্টির সময়ে ভুল।
দুই কার্যকর ফরম্যাট
ISO 8601 স্ট্রিং
{
"createdAt": "2026-10-30T14:30:00+08:00",
"updatedAt": "2026-10-30T06:30:00Z"
}
পাঠযোগ্য, ফরম্যাট সামঞ্জস্যপূর্ণ হলে সাজানো যায়, দরকারে মিলিসেকেন্ড নির্ভুলতা, আর স্ব-বর্ণনাকারী।
Epoch সংখ্যা
{ "createdAt": 1793519400 }
সংক্ষিপ্ত ও দ্ব্যর্থতিহীন, কিন্তু অপাঠ্য, আর সেকেন্ড বনাম মিলিসেকেন্ড চিরস্থায়ী বিপদ। Epoch বাছলে একক প্রমিত করুন আর ফিল্ড-নামে রাখুন: createdAtMs createdAt-এর চেয়ে অনেক নিরাপদ।
আগেই ঠিক করার যোগ্য প্রথা
| বিষয় | প্রথা |
|---|---|
| তারের ফরম্যাট | Z বা +08:00 সহ ISO 8601 |
| স্টোরেজ জোন | UTC, যাতে DST কখনো ছবিতে না আসে |
| নির্ভুলতা | মিলিসেকেন্ড যথেষ্ট |
| ফিল্ড নামকরণ | createdAt, updatedAt, expiresAt |
| কেবল তারিখ | আলাদা date ফিল্ড, যেমন birthday: "1990-01-01" |
| সময়কাল | ইন্টিজার প্লাস একক, যেমন timeoutMs: 3000 |
রেন্ডারিং
new Intl.DateTimeFormat('en-GB', {
dateStyle: 'medium',
timeStyle: 'short',
timeZone: 'Europe/London',
}).format(new Date('2026-10-30T06:30:00Z'));
প্রদর্শন ডিভাইস অনুসরণ করবে না হলে timeZone স্পষ্টভাবে দিন। ব্যবহারকারী-মুখী সময়ে ব্রাউজার ডিফল্টের উপর নির্ভর করা ঠিক, রিপোর্টে ভুল।
তিন বারবার ঘটে যাওয়া বাগ
খালি তারিখ UTC মিডনাইট হিসেবে পার্স হয়। ECMAScript স্পেসিফিকেশন অনুযায়ী কেবল-তারিখ স্ট্রিং UTC আর তারিখ-সময় স্ট্রিং লোকাল। এই অসামঞ্জস্য একদিন এদিক-ওদিক সরে যাওয়া বাগের নির্ভরযোগ্য উৎস।
ডেটাবেস জোন সিরিয়ালাইজারের সঙ্গে অমিল। MySQL datetime-এ জোন নেই; লোকালে লিখে UTC হিসেবে পড়লে সব offset-এ সরে যায়।
ডে-লাইট সেভিং। ভবিষ্যতের লোকাল সময় সংরক্ষণ করলে এমন সময়বিন্দু তৈরি হয় যা অস্তিত্ব নেই বা দুইবার ঘটে। UTC-তে এমন ফাঁক নেই।
সাধারণ প্রশ্ন
ISO 8601 ও epoch সংখ্যার মধ্যে কীভাবে বাছাই করব?
মানুষ পেললোড পড়লে, লেক্সিক্যাল সর্ট অর্ডার চাইলে, বা মান নিজের জোন বহন করতেই হবে তখন ISO 8601 ব্যবহার করুন; দাম প্রায় এক ডজন বাড়তি বাইট আর একটি পার্সিং লাইব্রেরি। সংক্ষিপ্ততা ও তুচ্ছ ক্রস-ভাষা হ্যান্ডলিং বেশি গুরুত্বপূর্ণ হলে epoch, কিন্তু সেকেন্ড বনাম মিলিসেকেন্ড সর্বত্র স্থির করুন আর ফিল্ডে কোন একক তা বলুন।
খালি তারিখ ও টাইমস্ট্যাম্প একই ফিল্ড ভাগ করতে পারে?
না। খালি 2026-10-30 একটি ক্যালেন্ডার দিন, সময় ও জোন নেই, অথচ টাইমস্ট্যাম্প ফিল্ডের কাছে নির্দিষ্ট সময়বিন্দু প্রত্যাশিত। জন্মদিন ও বিলিং সময়কাল আলাদা date ফিল্ডে রাখুন, আর সৃষ্টি বা হালনাগাদের সময়ে ISO 8601 At ফিল্ড ব্যবহার করুন।