Unix টাইমস্ট্যাম্প কনভার্টার
একটি Unix টাইমস্ট্যাম্প (epoch)-কে মানুষ-পঠনযোগ্য তারিখে ও ফিরিয়ে রূপান্তর করুন। সেকেন্ড বা মিলিসেকেন্ড, UTC, ISO 8601, লোকাল ও আপেক্ষিক আউটপুটসহ। সম্পূর্ণরূপে আপনার ব্রাউজারে চলে। সর্বশেষ পর্যালোচনা 2026-06-19.
বর্তমান Unix সময়: …
টাইমস্ট্যাম্প → তারিখ
- UTC
- —
- ISO 8601
- —
- লোকাল
- —
- আপেক্ষিক
- —
তারিখ → টাইমস্ট্যাম্প
Unix টাইমস্ট্যাম্প কী
একটি Unix টাইমস্ট্যাম্প (epoch / POSIX টাইম) 1 জানুয়ারি 1970 00:00:00 UTC থেকে
অতিবাহিত সেকেন্ড গণনা করে, leap second উপেক্ষা করে। যেহেতু এটি UTC-তে একটি একক সংখ্যা,
এটি টাইমজোন-নিরপেক্ষভাবে একটি সঠিক মুহূর্ত সংরক্ষণ করে — এ কারণেই ডেটাবেস, লগ ও API এটি
ব্যবহার করে। উদাহরণস্বরূপ, 1700000000 হলো Tue, 14 Nov 2023 22:13:20 GMT (ISO 8601:
2023-11-14T22:13:20.000Z)।
সেকেন্ড বনাম মিলিসেকেন্ড
প্রচলিত Unix টাইম সেকেন্ডে হয় (বর্তমান মান 10 অঙ্কের)। JavaScript ও অনেক প্ল্যাটফর্ম মিলিসেকেন্ড (13 অঙ্ক) ব্যবহার করে। আপনি যদি একক “স্বয়ংক্রিয় শনাক্ত”-এ রেখে 13-অঙ্কের মান পেস্ট করেন, তবে এই টুলটি সেটিকে মিলিসেকেন্ড হিসেবে ধরে। সেকেন্ডে সাধারণ ব্যবধান:
| ব্যবধান | সেকেন্ড |
|---|---|
| মিনিট | 60 |
| ঘণ্টা | 3,600 |
| দিন | 86,400 |
| সপ্তাহ | 604,800 |
| বছর (365 দিন) | 31,536,000 |
Year 2038 সমস্যা
যে সফটওয়্যার টাইমস্ট্যাম্পকে signed 32-bit ইন্টিজারে সংরক্ষণ করে তা কেবল 2,147,483,647 সেকেন্ড পর্যন্ত গণনা করতে পারে — যা 19 জানুয়ারি 2038-এ 03:14:07 UTC-তে পৌঁছায়। তার পরে মানটি ওভারফ্লো করে ঋণাত্মক সংখ্যা হয়ে যায়। সমাধান হলো সময়কে 64-bit ইন্টিজারে সংরক্ষণ করা, যা সমস্ত আধুনিক সিস্টেম করে থাকে।
1970 epoch কোথা থেকে এসেছে
পরিচিত 1970 শুরু-বিন্দুটি প্রথম ছিল না। Unix প্রোগ্রামার ম্যানুয়ালের প্রাচীনতম সংস্করণ, যা নভেম্বর 1971-তে Bell Labs-এ লেখা হয়েছিল, সিস্টেম সময়কে 1 জানুয়ারি 1971-এ 00:00:00 থেকে অতিবাহিত সেকেন্ডের ষাট ভাগের এক অংশের সংখ্যা হিসেবে সংজ্ঞায়িত করেছিল। 1/60-সেকেন্ড টিকে গণনা করা সেই 60 Hz লাইন-ফ্রিকোয়েন্সির সাথে মিলত যা দিয়ে প্রাথমিক PDP-11 হার্ডওয়্যার তার ঘড়ি চালাত, কিন্তু সেকেন্ডে 60 বার এগিয়ে যাওয়া একটি 32-bit কাউন্টার তার সীমা কেবল প্রায় 2.26 বছরে শেষ করে ফেলে — একটি পরবর্তী ম্যানুয়াল স্পষ্ট লিখেছিল যে এটি "প্রতি 2.26 বছরে একটি সংকটের গ্যারান্টি দেয়।"
সমাধানটি, যা 1972–1973 সালের ম্যানুয়ালগুলোতে নির্ধারিত হয়, ছিল দ্বিমুখী: টিকের বদলে পূর্ণ সেকেন্ড গণনা করো, এবং শূন্য-বিন্দুকে 1 জানুয়ারি 1970 UTC-এর গোলাকার তারিখে সরিয়ে নাও। ষাট ভাগের অংশ থেকে সেকেন্ডে যাওয়া এক ধাক্কায় ব্যবহারযোগ্য সীমাকে ষাট গুণ করে দেয়, এবং প্রকৌশলীরা — Ken Thompson, Dennis Ritchie ও সহকর্মীরা — 1970 বেছে নিয়েছিলেন কারণ এটি কাজ করার জন্য একটি সুবিধাজনক, পরিপাটি সংখ্যা ছিল। সেই স্বেচ্ছাচারী, বাস্তবসম্মত পছন্দটি তখন থেকে কম্পিউটিংয়ের সবচেয়ে নিঃশব্দে ভার-বহনকারী ধ্রুবকগুলোর একটি হয়ে উঠেছে: প্রতিটি আধুনিক অপারেটিং সিস্টেম, ডেটাবেস ও প্রোগ্রামিং ভাষা আজও সেই ঠিক মুহূর্ত থেকেই গণনা করে।
Leap second, এবং কেন প্রতিটি Unix দিন ঠিক 86,400 সেকেন্ডের
POSIX মানদণ্ড Unix টাইমকে এমনভাবে সংজ্ঞায়িত করে যে প্রতিটি দিনে ঠিক 86,400 সেকেন্ড থাকে (60 × 60 × 24)। এটি স্পষ্ট মনে হয় যতক্ষণ না আপনার মনে পড়ে যে নাগরিক সময় হলো UTC, এবং UTC মাঝে মাঝে পৃথিবীর সামান্য অনিয়মিত ঘূর্ণনের সাথে ঘড়িগুলোকে সারিবদ্ধ রাখতে একটি leap second যোগ করে। ধনাত্মক leap second-যুক্ত দিনে UTC প্রকৃতপক্ষে 86,401 সেকেন্ড চলে — কিন্তু Unix টাইমকে এটি স্বীকার করতে চুক্তিগতভাবে নিষেধ করা হয়েছে, তাই এটি অতিরিক্ত সেকেন্ডটি গণনাই করে না।
ফলাফল একটি ছোট কিন্তু বাস্তব অস্পষ্টতা। উদাহরণস্বরূপ, সীমা-মান 1483228800 হয় leap
second 2016-12-31 23:59:60 UTC বোঝাতে পারে অথবা এক টিক পরের সাধারণ সেকেন্ড
2017-01-01 00:00:00 UTC — দুটি ভিন্ন বাস্তব-জগতের মুহূর্ত একটি একই টাইমস্ট্যাম্প ভাগ করে,
কারণ একই Unix মান পরপর দুই সেকেন্ডের জন্য ব্যবহৃত হয় যাতে পরের মধ্যরাত তবুও 86,400-এর
পরিষ্কার গুণিতকে পড়ে। ব্যবহারিক ফলাফল: একটি সংরক্ষিত Unix টাইমস্ট্যাম্প কোনো leap second-কে দ্ব্যর্থহীনভাবে
উপস্থাপন করতে পারে না, এবং একটি leap second-এর দুই পাশে পড়া দুটি টাইমস্ট্যাম্পের মধ্যকার পার্থক্য মাঝের
leap second-এর সংখ্যার সমান ভুল হয়। বেশিরভাগ সফটওয়্যারের জন্য এটি অদৃশ্য; উচ্চ-নির্ভুল
সিস্টেম TAI ব্যবহার করে বা leap second-কে সারা দিন ধরে ধীরে ধীরে "smear" করে দেয়।
ঋণাত্মক টাইমস্ট্যাম্প: epoch-এর আগের সময় নির্দেশ করা
যেহেতু time_t একটি signed ইন্টিজার, টাইমস্ট্যাম্প 1970-এর পরের তারিখে
সীমাবদ্ধ নয় — সেগুলো অতীতের দিকে নির্দেশ করতে ঋণাত্মক হতে পারে, epoch-এর আগের
প্রতিটি সেকেন্ডের জন্য এক করে কমতে থাকে। 1 জানুয়ারি 1969 UTC-এর মধ্যরাত হলো -31536000 (ঠিক একটি
non-leap বছর আগে), এবং signed 32-bit ফিল্ড যে সবচেয়ে ঋণাত্মক মান ধরে রাখতে পারে,
-2147483648, পড়ে 13 ডিসেম্বর 1901-এ 20:45:52 UTC-তে — 2038 সীমার
আয়না-প্রতিবিম্ব। ঐতিহাসিক তারিখ সংরক্ষণের সময় ঋণাত্মক epoch স্বাভাবিক, কিন্তু এগুলো বারবার বাগের
উৎস: কোনো লাইব্রেরি বা ডেটাবেস কলাম যা ধরে নেয় টাইমস্ট্যাম্প unsigned, তা 1970-এর আগের
যেকোনো কিছু ভুলভাবে সামলাবে, এবং কিছু পুরনো সিস্টেম ঋণাত্মক মান সরাসরি প্রত্যাখ্যান করে।
উপ-সেকেন্ড নির্ভুলতা: মিলিসেকেন্ড, মাইক্রোসেকেন্ড, ন্যানোসেকেন্ড
সাধারণ Unix টাইমের রেজোলিউশন এক-সেকেন্ড, কিন্তু বেশিরভাগ প্ল্যাটফর্ম এটিকে বাড়ায়, এবং অঙ্কের
সংখ্যাই দ্রুততম শনাক্তকারী: একটি বর্তমান মান সেকেন্ডে 10 অঙ্ক, মিলিসেকেন্ডে 13, মাইক্রোসেকেন্ডে
16 এবং ন্যানোসেকেন্ডে 19 অঙ্কের। JavaScript মূলত মিলিসেকেন্ডে কাজ করে —
Date.now() একটি 13-অঙ্কের মান ফেরত দেয় — তাই প্রচলিত সেকেন্ডে রূপান্তর করতে 1,000 দিয়ে
ভাগ করতে হয়। Python-এর time.time() মাইক্রোসেকেন্ড নির্ভুলতাসহ সেকেন্ডের একটি
ফ্লোটিং-পয়েন্ট সংখ্যা ফেরত দেয়, যেখানে time.time_ns() ন্যানোসেকেন্ডের একটি ইন্টিজার গণনা
ফেরত দেয়। Go-এর time.Now().UnixNano() ও অনেক ডেটাবেসও ন্যানোসেকেন্ড পর্যন্ত পৌঁছায়। এই
এককগুলো মেশানো সবচেয়ে সাধারণ epoch বাগ — নিচের সমস্যাগুলো দেখুন।
যেকোনো পরিবেশে বর্তমান epoch পড়া
প্রায় প্রতিটি ভাষা ও শেল বর্তমান Unix টাইম সরাসরি প্রকাশ করে। নিচের টেবিলটি বেশ কিছু সাধারণ পরিবেশে প্রচলিত কল তালিকাভুক্ত করে (অন্যথা উল্লেখ না থাকলে, প্রতিটি পূর্ণ সেকেন্ড ফেরত দেয়):
| পরিবেশ | epoch কীভাবে পড়বেন |
|---|---|
| শেল (Linux / macOS) | date +%s |
| JavaScript | Math.floor(Date.now() / 1000) — Date.now() মিলিসেকেন্ডে |
| Python | int(time.time()) |
| PHP | time() |
| Go | time.Now().Unix() |
| Java | Instant.now().getEpochSecond() — মিলিসেকেন্ডের জন্য currentTimeMillis() |
| PostgreSQL | SELECT EXTRACT(EPOCH FROM now()) |
| MySQL | SELECT UNIX_TIMESTAMP() |
Unix-ই একমাত্র শূন্য-বিন্দু নয়
বিভিন্ন সিস্টেম বিভিন্ন epoch-কে কেন্দ্র করে ডিজাইন করা হয়েছিল, এ কারণেই "কোনো epoch থেকে অতিবাহিত সেকেন্ড" ততক্ষণ অর্থহীন যতক্ষণ না আপনি জানেন কোন epoch, এবং এ কারণেই রূপান্তর ছাড়া টাইমস্ট্যাম্প প্ল্যাটফর্মের মধ্যে পোর্টেবল নয়। সবচেয়ে গুরুত্বপূর্ণ রেফারেন্স-বিন্দুগুলো:
| সিস্টেম | epoch (শূন্য-বিন্দু) | একক | মন্তব্য |
|---|---|---|---|
| Unix / POSIX | 1970-01-01 UTC | সেকেন্ড | ওয়েব ও বেশিরভাগ অপারেটিং সিস্টেম। |
| NTP | 1900-01-01 UTC | সেকেন্ড | 32-bit সেকেন্ড-কাউন্টার 7 ফেব্রুয়ারি 2036-এ রোল-ওভার করে। |
| GPS | 1980-01-06 UTC | সেকেন্ড / সপ্তাহ | leap second উপেক্ষা করে, তাই এখন এটি UTC-এর চেয়ে 18 সেকেন্ড এগিয়ে চলে। |
| Windows FILETIME | 1601-01-01 UTC | 100-ন্যানোসেকেন্ড টিক | 1601 একটি 400-বছরের Gregorian চক্র শুরু করে। |
| Excel সিরিয়াল তারিখ | 1899-12-30 | দিন | 1900-কে leap বছর হিসেবে গণ্য করে (Lotus 1-2-3 সামঞ্জস্যের জন্য রাখা একটি বাগ)। |
Excel-এর খামখেয়ালিপনাটি ক্লাসিক গোলযোগ: Lotus 1-2-3-এর সাথে বাগ-সামঞ্জস্যপূর্ণ থাকতে, Excel বিশ্বাস করে অস্তিত্বহীন তারিখ 29 ফেব্রুয়ারি 1900 বাস্তব ছিল, তাই 1900-এর গোড়ার যেকোনো তারিখের জন্য তার দিন-কাউন্টার এক দিয়ে ভুল হয়, এবং তা পুষিয়ে নিতে তার কার্যকর epoch 30 ডিসেম্বর 1899-এ স্থির করা। Windows 1601 ব্যবহার করে কারণ সেই বছরটি Gregorian ক্যালেন্ডারের 400-বছরের চক্র শুরু করে, যা leap-বছর গণনাকে পরিষ্কার রাখে।
মাইলফলক টাইমস্ট্যাম্প ও 292-বিলিয়ন-বছরের দিগন্ত
যেহেতু Unix টাইম কেবল একটি কাউন্টার, কিছু গোলাকার বা কৌতূহলোদ্দীপক মান ছোটখাটো গিক উৎসব হয়ে উঠেছে:
| টাইমস্ট্যাম্প | মুহূর্ত (UTC) | এটি কেন উল্লেখযোগ্য |
|---|---|---|
1000000000 | 2001-09-09 01:46:40 | প্রথম "Unix billennium" — এক বিলিয়ন সেকেন্ড। |
1234567890 | 2009-02-13 23:31:30 | অঙ্ক 1-2-3-4-5-6-7-8-9-0 ক্রমানুসারে; Google একটি ডুডল চালিয়েছিল। |
1700000000 | 2023-11-14 22:13:20 | এই পৃষ্ঠার উপরের ওয়ার্কড উদাহরণে ব্যবহৃত মান। |
2000000000 | 2033-05-18 03:33:20 | দ্বিতীয় billennium। |
2147483647 | 2038-01-19 03:14:07 | signed 32-bit সীমা — Year 2038 রোল-ওভার। |
2038-এর পরে দীর্ঘমেয়াদি উত্তর ইতিমধ্যে মোতায়েন: গণনাকে signed 64-bit ইন্টিজারে
সংরক্ষণ করা ওভারফ্লোকে 1970-এর যেকোনো দিকে প্রায় 292 বিলিয়ন বছর ঠেলে দেয় —
সূর্যের প্রক্ষিপ্ত জীবনকাল ছাড়িয়ে অনেক দূরে। আধুনিক Linux, C লাইব্রেরি ও বেশিরভাগ ভাষা বহু বছর আগে 64-bit
time_t-তে চলে এসেছে; অবশিষ্ট 2038 ঝুঁকি রয়ে গেছে পুরনো 32-bit বাইনারি, এমবেডেড ফার্মওয়্যার এবং
সেইসব পুরনো অন-ডিস্ক বা অন-ওয়্যার ফরম্যাটে যা এখনও টাইমস্ট্যাম্পকে 32 বিটে প্যাক করে।
epoch নিয়ে কাজ করার সময় সাধারণ সমস্যা
- সেকেন্ড বনাম মিলিসেকেন্ড। 10-অঙ্কের মান সেকেন্ড; 13 অঙ্ক মিলিসেকেন্ড। মিলিসেকেন্ড প্রত্যাশা করা API-কে সেকেন্ড দিলে তারিখটি ফিরে 1970-তে পড়ে যায়, আর উল্টোটা করলে তা হাজার হাজার বছর ভবিষ্যতে লাফিয়ে যায়।
- বাদ পড়া (বা অতিরিক্ত) ×1000। JavaScript-এর
new Date(n)মিলিসেকেন্ড প্রত্যাশা করে, তাই সেকেন্ড মান দিলেn * 1000প্রয়োজন — এটি ভুলে যাওয়া সবচেয়ে সাধারণ epoch বাগ। - epoch-কে লোকাল সময় ধরে নেওয়া। একটি Unix টাইমস্ট্যাম্প সর্বদা UTC। টাইমজোন নির্দিষ্ট না করে এটি উপস্থাপন করলে প্রদর্শিত সময় আপনার মেশিনের অফসেট পরিমাণ নিঃশব্দে সরে যায়।
- অফ-বাই-ওয়ান রাউন্ডিং। মিলিসেকেন্ডকে সেকেন্ডে রূপান্তর করার সময় সাধারণত floor করা উচিত, round নয়, নইলে কোনো ঘটনা বাস্তব সময়ের এক সেকেন্ড পরে ঘটেছে বলে দেখা দিতে পারে।
- unsigned ধরে নেওয়া। 1970-এর আগের তারিখ ঋণাত্মক; যে কোড বা কলাম non-negative টাইমস্ট্যাম্প ধরে নেয় তা ঐতিহাসিক ডেটা বিকৃত করবে।
ওয়াল-ক্লক সময় বনাম মনোটোনিক সময়
একটি ফাঁদ যা অভিজ্ঞ ডেভেলপারদেরও ধরে ফেলে: একটি Unix টাইমস্ট্যাম্প হলো ওয়াল-ক্লক সময়, এবং
ওয়াল-ক্লক সময় লাফ দিতে পারে। NTP সংশোধন এটিকে সামনে-পিছনে ঠেলে দেয়, একজন প্রশাসক এটি রিসেট করতে
পারেন, টাইমজোন-ডেটাবেস আপডেট লোকাল উপস্থাপনা বদলে দেয়, এবং leap-second smearing ইচ্ছাকৃতভাবে একটি দিনের
জন্য এটিকে ধীর বা দ্রুত করে। ফলস্বরূপ, কোনো অপারেশনে কত সময় লেগেছে তা মাপতে দুটি Unix
টাইমস্ট্যাম্প বিয়োগ করলে ঋণাত্মক বা এলোমেলো ভুল সময়কাল ফেরত আসতে পারে যদি মাঝে ঘড়ি সমন্বিত হয়ে থাকে।
অতিবাহিত সময় মাপতে আপনার বরং একটি মনোটোনিক ঘড়ি পড়া উচিত — যা কেবল
সামনের দিকে এগোয় এবং ওয়াল-ক্লক সমন্বয় থেকে অপ্রভাবিত থাকে — যেমন ব্রাউজারে
performance.now(), Python-এ time.monotonic(), বা Linux-এ
CLOCK_MONOTONIC। কিছু কখন ঘটেছে তা রেকর্ড করতে Unix epoch ব্যবহার করুন;
কিছুতে কত সময় লেগেছে তা মাপতে একটি মনোটোনিক ঘড়ি ব্যবহার করুন।
ফরম্যাট করা তারিখের বদলে কেন epoch সংরক্ষণ করবেন
যখন আপনি স্টোরেজ ফরম্যাট নিয়ন্ত্রণ করেন, একটি কাঁচা Unix ইন্টিজার প্রায় সবসময়ই মানুষ-পঠনযোগ্য স্ট্রিংয়ের চেয়ে
ভালো পছন্দ। এটি সংক্ষিপ্ত, একটি সাধারণ সংখ্যার মতো সঠিকভাবে সাজানো হয়, তুলনা ও
গণিত করা সহজ, এবং — গুরুত্বপূর্ণভাবে — কোনো টাইমজোন অস্পষ্টতা বহন করে না, কারণ এটি সর্বদা
UTC। তুলনায় "01/02/03"-এর মতো একটি স্ট্রিং হতাশাজনক: এটি লোকেল অনুযায়ী তিনটি ভিন্ন তারিখ হতে পারে,
এবং একে বিয়োগ করা যায় না। আপনার যখন সত্যিই টেক্সট প্রয়োজন তখন মানক বিনিময় ফরম্যাট হলো ISO 8601 /
RFC 3339 (উদাহরণস্বরূপ 2009-02-13T23:31:30Z), যার শেষের "Z" একে UTC-তে
স্থির করে এবং যার আভিধানিক ক্রম কালানুক্রমিক ক্রমের সাথে মেলে। বুড়ো আঙুলের নিয়ম: epoch (বা একটি
স্পষ্ট-UTC ISO 8601 স্ট্রিং) সংরক্ষণ ও প্রেরণ করুন, এবং একে লোকাল, মানুষ-বান্ধব টেক্সটে কেবল
একেবারে শেষ মুহূর্তে, ইউজার ইন্টারফেসে ফরম্যাট করুন।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
- Unix টাইমস্ট্যাম্প কী?
- একটি Unix টাইমস্ট্যাম্প (যাকে epoch বা POSIX টাইমও বলা হয়) হলো 1 জানুয়ারি 1970-এ 00:00:00 UTC ("Unix epoch") থেকে অতিবাহিত সেকেন্ডের সংখ্যা, leap second গণনা না করে। এটি একটি মুহূর্তকে টাইমজোন-নিরপেক্ষ উপায়ে সংরক্ষণের একটি পদ্ধতি।
- টাইমস্ট্যাম্প কি সেকেন্ডে না মিলিসেকেন্ডে?
- Unix টাইমস্ট্যাম্প প্রচলিতভাবে সেকেন্ডে হয় (বর্তমান তারিখের জন্য 10 অঙ্ক)। JavaScript, Java ও অনেক API মিলিসেকেন্ড (13 অঙ্ক) ব্যবহার করে। এই টুলটি আপনাকে একক বেছে নিতে দেয়, এবং 13-অঙ্কের ইনপুটকে স্বয়ংক্রিয়ভাবে মিলিসেকেন্ড হিসেবে শনাক্ত করে।
- Year 2038 সমস্যা কী?
- যেসব সিস্টেম টাইমস্ট্যাম্পকে signed 32-bit ইন্টিজারে সংরক্ষণ করে, সেগুলো 19 জানুয়ারি 2038-এ 03:14:07 UTC-তে ওভারফ্লো করে, যখন মানটি 2,147,483,647 ছাড়িয়ে যায়। আধুনিক 64-bit সিস্টেম অপ্রভাবিত; সমাধান হলো সময়কে 64-bit ইন্টিজারে সংরক্ষণ করা।
- রূপান্তরটি কি আপনার সার্ভারে ঘটে?
- না। এটি সম্পূর্ণরূপে আপনার ব্রাউজারে নেটিভ Date API দিয়ে চলে, তাই আপনার মান কখনো আপলোড হয় না। একবার লোড হয়ে গেলে এটি অফলাইনেও কাজ করে।