API ও লগে Epoch Time ব্যাখ্যা: কীভাবে ঠিকভাবে পড়বেন এবং রূপান্তর করবেন
Epoch time এমন এক প্রযুক্তিগত ফরম্যাট যা সর্বত্র দেখা যায়, কিন্তু মানুষের জন্য আশ্চর্যজনকভাবে অমৈত্রীপূর্ণ।
আপনি কোনো API রেসপন্স, লগ এন্ট্রি বা ডাটাবেস রেকর্ডে একটি দীর্ঘ পূর্ণসংখ্যা দেখেন এবং সঙ্গে সঙ্গে বুঝতে পারেন এটি একটি তারিখ ও সময় বোঝায়—কিন্তু আগে রূপান্তর না করলে এমন কোনো তারিখ-সময় নয় যা মানুষ সহজে পড়ে নিতে পারে।
তাই মানুষ epoch time কী, epoch time converter, এবং লগে Unix timestamp কীভাবে পড়ব—এসব খোঁজে। সিস্টেমের জন্য সংখ্যাটি সহজ, কিন্তু ডিবাগ, অডিট বা ইভেন্ট তুলনা করতে চাইলে মানুষের জন্য তা স্বাভাবিক নয়।
Epoch Time আসলে কী বোঝায়
Epoch time সাধারণত বোঝায় কত সেকেন্ড পেরিয়েছে এই সময় থেকে:
January 1, 1970, 00:00:00 UTC
এই রেফারেন্স পয়েন্টকে সাধারণত Unix epoch বলা হয়।
তাই আপনি যদি এমন একটি সংখ্যা দেখেন:
1711929600
তাহলে তা ওই নির্দিষ্ট শুরুর মুহূর্ত থেকে গোনা একটি নির্দিষ্ট সময়-মুহূর্তকে প্রতিনিধিত্ব করে।
এই কারণেই epoch time-কে অনেক সময় Unix timestampও বলা হয়।
আপনি যদি কোনো timestamp দ্রুত মানুষের পড়ার মতো তারিখে রূপান্তর করতে চান, Unix Timestamp Converter সবচেয়ে সহজ উপায়।
কেন API ও লগে Epoch Time ব্যবহার করা হয়
সিস্টেমগুলো epoch time ব্যবহার করে কারণ এটি:
- সংক্ষিপ্ত (compact)
- সাজানো যায় (sortable)
- দ্ব্যর্থহীন (unambiguous)
- গণিতের মতো করে তুলনা করা সহজ
যেমন:
04/03/2026 10:15 PM
এমন স্ট্রিং লোকেল, ফরম্যাট ও টাইম জোন অনুযায়ী ভিন্নভাবে ব্যাখ্যা হতে পারে।
Unix timestamp সেই দ্ব্যর্থতা দূর করে। মেশিন সহজে এটি সংরক্ষণ করতে পারে, তুলনা করতে পারে, এবং কীভাবে পড়তে হবে তা নিয়ে তর্ক ছাড়াই সিস্টেমের মধ্যে আদান-প্রদান করতে পারে।
তাই এটি দেখা যায়:
- API payloads-এ
- অ্যাপ্লিকেশন লগে
- অ্যানালিটিক্স ইভেন্টে
- cache expiration logic-এ
- ডাটাবেস ফিল্ডে
Seconds বনাম Milliseconds: সবচেয়ে সাধারণ সমস্যা
এখানেই অনেকেই আটকে যান।
কিছু সিস্টেম epoch time সংরক্ষণ করে:
- seconds-এ
আর কিছু সিস্টেম ব্যবহার করে:
- milliseconds-এ
উদাহরণ:
- Seconds:
1711929600 - Milliseconds:
1711929600000
আপনি যদি milliseconds-কে seconds ধরে নেন, রূপান্তরিত তারিখ ভয়াবহভাবে ভুল হবে। উল্টোটা হলেও একই সমস্যা হয়।
JavaScript, ব্যাক-এন্ড সার্ভিস ও ডাটাবেসের মধ্যে কাজ করতে গিয়ে এটি সবচেয়ে সাধারণ ডিবাগিং ভুলগুলোর একটি।
কেন UTC গুরুত্বপূর্ণ
Epoch time UTC-ভিত্তিক, আপনার লোকাল টাইম জোন-ভিত্তিক নয়।
অর্থাৎ timestamp নিজেই একটি সার্বজনীন মুহূর্তকে প্রতিনিধিত্ব করে। লোকালভাবে দেখানো সময় নির্ভর করে আপনি কোথায় এবং কীভাবে রূপান্তর করছেন তার ওপর।
তাই একই timestamp দেখা যেতে পারে:
- এক অঞ্চলে এক ক্যালেন্ডার তারিখ হিসেবে
- অন্য জায়গায় ভিন্ন লোকাল ঘড়ির সময় হিসেবে
timestamp বদলায় না। বদলায় শুধু মানুষের পড়ার মতো ব্যাখ্যাটি।
কেন ডেভেলপার ও অ্যানালিস্টদের মানুষের মতো পড়ার জন্য রূপান্তর দরকার
মেশিন epoch time-এ একদম স্বাচ্ছন্দ্য। মানুষ নয়।
আপনি যদি এমন প্রশ্নের উত্তর খুঁজতে চান:
- এই ইভেন্টটি কবে ঘটেছে?
- কোন রিকোয়েস্টটি আগে এসেছে?
- এই দুই ইভেন্টের মধ্যে কত সময় পার হয়েছে?
- এটি মধ্যরাতের আগে এক্সপায়ার হয়েছে নাকি পরে?
তাহলে সাধারণত আপনাকে timestamp-কে পড়ার মতো তারিখ-সময়ে রূপান্তর করতে হয়।
র’ ভ্যালু রূপান্তরিত হলে ম্যানুয়াল ডিবাগিং অনেক সহজ হয়ে যায়।
Duration হিসাবের সঙ্গে Epoch Time-এর সম্পর্ক
Timestamp রূপান্তর বা সংখ্যাগতভাবে তুলনা করার পর পরই পরের প্রশ্ন হয় duration।
যেমন:
- দুইটি ইউজার ইভেন্টের মধ্যে কত দিন পার হয়েছে?
- অ্যাকাউন্ট তৈরি থেকে শেষ অ্যাক্টিভিটি পর্যন্ত কত সময়?
- দুইটি সিস্টেম রেকর্ডের মধ্যে কত দিন?
তাই Unix timestamp নিয়ে কাজ প্রায়ই date-interval লজিকের সঙ্গে ওভারল্যাপ করে। সমস্যা যখন “এই মুহূর্তটা কখন?” থেকে “এই দুই মুহূর্তের মধ্যে কত সময়?”-এ যায়, তখন Days Between Dates Calculator কাজে লাগে।
সাধারণ ভুলগুলো
1. Seconds ও Milliseconds গুলিয়ে ফেলা
এটাই এখন পর্যন্ত সবচেয়ে বেশি ঘটে।
2. Timestamp যে UTC-তে তা ভুলে যাওয়া
অনেকে মনে করেন মানটা বদলেছে, অথচ শুধু ডিসপ্লে টাইম জোন বদলেছে।
3. Raw timestamp না দেখে human-formatted তারিখ তুলনা করা
সিস্টেম কাজের জন্য timestamp সাধারণত তুলনার বেশি নিরাপদ ফরম্যাট।
4. রূপান্তর ছাড়াই timestamp-কে পড়ার মতো ধরে নেওয়া
প্যাটার্নটা চিনতে পারলেও, একটি দীর্ঘ পূর্ণসংখ্যাকে কার্যকর করতে সাধারণত অনুবাদ/রূপান্তর দরকার।
একটি বাস্তব উদাহরণ
ধরা যাক দুইটি লগে আছে:
17119296001712016000
মানুষের মতো পড়ার তারিখে রূপান্তর না করেও আপনি এগুলো বিয়োগ করে সেকেন্ডে পার্থক্য বের করতে পারেন। রূপান্তরের পর সেই ফলাফল বাস্তব ক্যালেন্ডার সময় হিসেবে অর্থবহ হয়।
এ কারণেই সিস্টেমের কাজে epoch timestamp এত উপকারী: মেশিনের জন্য তুলনা করা সহজ, এবং ঠিকভাবে রূপান্তর করলে মানুষের জন্যও বোঝা সহজ।
শেষ কথা
আপনি যদি API ও লগে epoch time বুঝতে চান, মূল বিষয়গুলো সহজ: এটি ১ জানুয়ারি ১৯৭০ UTC থেকে কেটে যাওয়া সেকেন্ড বোঝায়, সিস্টেমে এটি ব্যবহৃত হয় কারণ এটি দ্ব্যর্থহীন, এবং সবচেয়ে সাধারণ বিভ্রান্তি হলো seconds বনাম milliseconds।
র’ epoch time-কে পড়ার মতো তারিখে বদলাতে Unix Timestamp Converter ব্যবহার করুন, আর পরের প্রশ্ন যদি হয় দুইটি ইভেন্টের মধ্যে কত সময় কেটেছে—তাহলে Days Between Dates Calculator ব্যবহার করুন।