Unix টাইমস্ট্যাম্প কনভার্টার
নতুনepoch সময়কে তারিখে ও আবার ফিরিয়ে রূপান্তর করুন — লাইভ বর্তমান সময় ও ISO 8601 সহ।
Paste any Unix timestamp (seconds or ms) or click Now — Discord renders these tags dynamically for every reader.
Runs entirely in your browser. Nothing is uploaded.
Unix timestamp থেকে তারিখ — এবং উল্টোটাও — তাৎক্ষণিকভাবে
এই Unix timestamp কনভার্টার যেকোনো epoch time-কে মানুষের পাঠযোগ্য তারিখে রূপান্তর করে এবং যেকোনো তারিখকে আবার timestamp-এ ফিরিয়ে দেয় — পুরোটাই আপনার ব্রাউজারে। একটি লাইভ টিকার বর্তমান Unix time সেকেন্ড ও মিলিসেকেন্ড উভয় রূপেই চলমান দেখায়, তাই কপি করার জন্য সবসময় একটি টাটকা epoch হাতের কাছে থাকে। কোনো সাইনআপ নেই, কোনো সার্ভার নেই, কিছুই আপলোড হয় না।
যেকোনো সংখ্যা পেস্ট করুন, আর টুলটি নিজে থেকেই শনাক্ত করে সেটি সেকেন্ডে (১০ ডিজিট), মিলিসেকেন্ডে (১৩ ডিজিট), নাকি মাইক্রোসেকেন্ডে (১৬–১৭ ডিজিট) আছে। এরপর ফলাফলটি দেখায় আপনার স্থানীয় সময়ে, UTC-তে, ISO 8601-এ, RFC 2822-এ, এবং “৩ ঘণ্টা আগে”-র মতো একটি সহজবোধ্য আপেক্ষিক ফরম্যাটে। প্রতিটি আউটপুটের সাথে এক-ক্লিকের কপি বাটন থাকে।
Timestamp → তারিখ এবং তারিখ → timestamp
Timestamp → তারিখ প্যানেলটি যেকোনো ধনাত্মক বা ঋণাত্মক Unix timestamp গ্রহণ করে। ঋণাত্মক timestamp ১৯৭০-এর আগের তারিখ বোঝায় — Unix timestamp −৮৬,৪০০ হলো ৩১ ডিসেম্বর ১৯৬৯, ০০:০০:০০ UTC। আপনি ঠিক কোন ফরম্যাটের সংখ্যা হাতে পেয়েছেন তা জানা থাকলে স্বয়ংক্রিয়ভাবে শনাক্ত হওয়া এককটি ওভাররাইড করে সেকেন্ড, মিলিসেকেন্ড বা মাইক্রোসেকেন্ড জোর করে নির্ধারণ করে দিতে পারেন।
তারিখ → timestamp প্যানেলটি উল্টো দিকে কাজ করে: যেকোনো তারিখ ও সময় বেছে নিন, সম্পূর্ণ IANA টাইমজোন তালিকা থেকে আপনার টাইমজোন নির্বাচন করুন, এবং সেই মুহূর্তটির জন্য নির্ভুল Unix সেকেন্ড ও মিলিসেকেন্ড পেয়ে যান। এটি ডিফল্টভাবে বর্তমান সময় দেখায়, তাই আজকের epoch তাৎক্ষণিকভাবে দেখতে পাবেন।
Discord timestamp ট্যাগ — সাতটি ফরম্যাটই তৈরি করুন
Discord চ্যাট মেসেজে Unix timestamp রেন্ডার করে <t:1700000000:F>-এর মতো ট্যাগ দিয়ে, যা Discord-এর ক্লায়েন্ট প্রতিটি পাঠকের স্থানীয় টাইমজোনে স্বয়ংক্রিয়ভাবে দেখায়। সাতটি ফরম্যাট কোড আছে: t (সংক্ষিপ্ত সময়), T (দীর্ঘ সময়), d (সংক্ষিপ্ত তারিখ), D (দীর্ঘ তারিখ), f (সংক্ষিপ্ত তারিখ ও সময় — ডিফল্ট), F (সপ্তাহের দিনসহ দীর্ঘ তারিখ ও সময়), এবং R (আপেক্ষিক — “৩ ঘণ্টার মধ্যে”, “২ বছর আগে”)।
বেশিরভাগ Discord timestamp জেনারেটর সাতটির মধ্যে মাত্র এক বা দুটি ফরম্যাট তৈরি করে — hammertime.cyou সাতটিই তৈরি করে, তবে সেটির জন্য আলাদা সাইটে যেতে হয় এবং কোনো epoch স্বয়ংক্রিয় শনাক্তকরণ নেই। এই টুলটি সাতটি ফরম্যাটই একসাথে তৈরি করে, প্রতিটি আপনার স্থানীয় সময়ে কেমন দেখাবে তার একটি প্রিভিউসহ, এবং প্রতিটি ট্যাগের জন্য একটি কপি বাটনসহ। এটি iPhone, Android এবং ডেস্কটপে কাজ করে।
EpochConverter.com ও unixtimestamp.com-এর সাথে তুলনা
EpochConverter.com এই শ্রেণির শীর্ষে — এটি সেকেন্ড ও মিলিসেকেন্ড timestamp ভালোভাবে সামলায় এবং দ্রুত। কিন্তু এটি স্কেল স্বয়ংক্রিয়ভাবে শনাক্ত করে না (আপনাকে সেকেন্ড বনাম ms নির্দিষ্ট করতে হয়), কোনো Discord ট্যাগ জেনারেটর নেই, এবং মাইক্রোসেকেন্ড সাপোর্ট দেখায় না। unixtimestamp.com আরও সরল — শুধু সেকেন্ড, কোনো Discord আউটপুট নেই, কোনো আপেক্ষিক সময় নেই।
এই টুলটি ডিজিট সংখ্যা দিয়ে তিনটি স্কেলই স্বয়ংক্রিয়ভাবে শনাক্ত করে, সাতটি Discord ফরম্যাট ট্যাগ তৈরি করে, আপেক্ষিক সময় দেখায়, এবং কোনো অ্যাকাউন্ট ছাড়া সম্পূর্ণভাবে আপনার ব্রাউজারে চলে। যেসব ডেভেলপারকে লগ ফাইল, API রেসপন্স এবং Discord বট একটিই ট্যাবে ডিবাগ করতে হয়, তাদের জন্য এই সমন্বয়টি ওই দুটি সাইটের কোনোটিতেই নেই।
সেকেন্ড, মিলিসেকেন্ড ও মাইক্রোসেকেন্ড স্বয়ংক্রিয় শনাক্তকরণ
Unix timestamp নিয়ে বিভ্রান্তির সবচেয়ে সাধারণ উৎস হলো স্কেল। 1700000000-এর মতো একটি সেকেন্ড timestamp-এ ১০টি ডিজিট থাকে এবং এটি নভেম্বর ২০২৩-এর একটি তারিখ বোঝায়। একই মুহূর্ত মিলিসেকেন্ড timestamp হিসেবে হয় 1700000000000 — ১৩ ডিজিট, এক হাজার গুণ বড়। JavaScript-এর Date.now() মিলিসেকেন্ড ফেরত দেয়; Unix শেল কমান্ড date +%s সেকেন্ড ফেরত দেয়। API ও ডেটাবেস এক্ষেত্রে ব্যাপকভাবে ভিন্ন হয়।
১৬ ও ১৭ ডিজিটের timestamp হলো মাইক্রোসেকেন্ড — উচ্চ-নির্ভুলতার সেন্সর ডেটা, ডিস্ট্রিবিউটেড ট্রেসিং এবং কিছু NoSQL ডেটাবেসে ব্যবহৃত। এই কনভার্টার ডিজিট সংখ্যা দিয়ে স্কেল শনাক্ত করে এবং প্রতিবারই সঠিকভাবে রূপান্তর করে। আপনি চাইলে শনাক্তকরণটি ওভাররাইড করে একটি নির্দিষ্ট একক জোর করে দিতে পারেন।
Python, JavaScript ও SQL-এ epoch রূপান্তর
Python-এ, UTC-র জন্য datetime.fromtimestamp(ts, tz=timezone.utc) দিয়ে রূপান্তর করুন, অথবা সার্ভারের স্থানীয় টাইমজোনে ফলাফল পেতে tz বাদ দিন (যা ভিন্ন মেশিনে বাগ তৈরি করে)। বর্তমান সেকেন্ড timestamp হলো int(time.time()); মিলিসেকেন্ড হলো int(time.time() * 1000)। JavaScript-এ, new Date(ts * 1000) একটি সেকেন্ড timestamp-কে Date অবজেক্টে রূপান্তর করে; Date.now() বর্তমান মিলিসেকেন্ড epoch দেয়।
MySQL-এ, UNIX_TIMESTAMP() বর্তমান epoch সেকেন্ডে ফেরত দেয় এবং FROM_UNIXTIME(ts) আবার datetime-এ রূপান্তর করে। PostgreSQL-এ, EXTRACT(EPOCH FROM timestamptz) সেকেন্ড epoch দেয় এবং TO_TIMESTAMP(ts) উল্টো দিকে রূপান্তর করে। এই টুলটি সেই প্রান্তিক পরিস্থিতিগুলো সামলায় যা ডেভেলপারদের বিভ্রান্ত করে: Year 2038 সমস্যা, ১৯৭০-এর আগের ঋণাত্মক timestamp, এবং তিনটি নির্ভুলতা স্কেলই।
কেন ১ জানুয়ারি ১৯৭০? Unix epoch-এর উৎপত্তি
Unix epoch হিসেবে ১ জানুয়ারি ১৯৭০, ০০:০০:০০ UTC বেছে নেওয়াটা আনুষ্ঠানিক নয়, বরং বাস্তবসম্মত কারণে হয়েছিল। Bell Labs-এর প্রকৌশলীদের ১৯৬৯–১৯৭১-এর দিকে প্রথম Unix সিস্টেম তৈরির সময় একটি নির্দিষ্ট রেফারেন্স পয়েন্ট দরকার ছিল। তাঁরা বর্তমানের কাছাকাছি একটি গোল সংখ্যা চেয়েছিলেন, যাতে সাধারণ timestamp-গুলো ছোট, ধনাত্মক পূর্ণসংখ্যা হয় এবং সেই সময়ের ৩২-বিট ওয়ার্ডে আরামে ধরে যায়। কাজটি যখন হচ্ছিল, তার নিকটতম গোল বছর ছিল ১৯৭০, আর সেটিই স্থায়ীভাবে থেকে গেল।
একটি গুরুত্বপূর্ণ সূক্ষ্মতা হলো POSIX time লিপ সেকেন্ড উপেক্ষা করে। পৃথিবীর ঘূর্ণনের সাথে পারমাণবিক সময় সামঞ্জস্য রাখতে UTC মাঝে মাঝে একটি লিপ সেকেন্ড যোগ করে — যেমন ২০১৬-এর শেষে একটি লিপ সেকেন্ড যোগ হয়েছিল। POSIX প্রতিটি দিনকে ঠিক ৮৬,৪০০ সেকেন্ড হিসেবেই ধরে, তাই লিপ সেকেন্ড ঘটুক বা না ঘটুক, Unix timestamp 1483228800 হলো 2017-01-01 00:00:00 UTC। এর মানে Unix time নিখুঁতভাবে SI সেকেন্ডের রৈখিক গণনা নয়, তবে প্রায় প্রতিটি অ্যাপ্লিকেশন যে তারিখ–সময় রূপান্তর নিয়ে ভাবে, তার জন্য এটি সামঞ্জস্যপূর্ণ ও দ্ব্যর্থহীন।
UTC (Coordinated Universal Time) এবং GMT (Greenwich Mean Time) প্রায়ই ডকুমেন্টেশনে একই অর্থে ব্যবহার হয়, কিন্তু কারিগরিভাবে এরা আলাদা। GMT একটি জ্যোতির্বৈজ্ঞানিক মান, যা পৃথিবীর ঘূর্ণনের উপর ভিত্তি করে; UTC পারমাণবিক ঘড়ি দিয়ে রক্ষণাবেক্ষণ করা হয় এবং লিপ সেকেন্ড যোগ করে GMT-র ০.৯ সেকেন্ডের মধ্যে রাখা হয়। সব বাস্তব timestamp কাজের জন্য এই পার্থক্য অপ্রাসঙ্গিক — দুটির মধ্যে সেকেন্ডের ভগ্নাংশমাত্র পার্থক্য হয় — তবে Unix time-এ ব্যবহৃত রেফারেন্সের জন্য UTC-ই সঠিক পরিভাষা।
Year 2038 সমস্যা: যখন ৩২-বিট timestamp উপচে যায়
একটি ৩২-বিট সাইনড পূর্ণসংখ্যা −২,১৪৭,৪৮৩,৬৪৮ থেকে ২,১৪৭,৪৮৩,৬৪৭ পর্যন্ত মান ধারণ করতে পারে। Unix timestamp যখন এই টাইপে সংরক্ষণ করা হয় — যেমন আদি Linux কার্নেল এবং ৬৪-বিট কম্পিউটিং সর্বজনীন হওয়ার আগে লেখা অনেক C প্রোগ্রামে হতো — তখন কাউন্টারটি ১৯ জানুয়ারি ২০৩৮, ০৩:১৪:০৭ UTC-তে তার সর্বোচ্চ সীমায় পৌঁছায়। এক সেকেন্ড পরে মানটি সবচেয়ে বড় ঋণাত্মক ৩২-বিট পূর্ণসংখ্যায় গড়িয়ে যায়, যাকে সিস্টেম ১৯০১ সালের ডিসেম্বরের একটি তারিখ হিসেবে ব্যাখ্যা করে। এটিই Year 2038 সমস্যা, যাকে কখনও কখনও Y2K38 বলা হয়।
বাস্তব ঝুঁকিটি কেন্দ্রীভূত থাকে সেইসব দীর্ঘস্থায়ী কোডবেসে যেগুলো কখনও আধুনিক করা হয়নি: শিল্প নিয়ন্ত্রক ও চিকিৎসা যন্ত্রের এমবেডেড সিস্টেম, নেটওয়ার্ক যন্ত্রপাতির ফার্মওয়্যার, যেসব পুরনো ডেটাবেস স্কিমা timestamp-কে যথাযথ datetime টাইপের বদলে INT কলামে রাখে, এবং লিগ্যাসি C লাইব্রেরি। সমাধানটি নীতিগতভাবে সরল — ৬৪-বিট পূর্ণসংখ্যায় স্থানান্তর করুন, যা ওভারফ্লোর তারিখকে প্রায় ২৯২ বিলিয়ন বছর ভবিষ্যতে ঠেলে দেয় — কিন্তু প্রতিটি আক্রান্ত সিস্টেম খুঁজে বের করে হালনাগাদ করতে সময় ও পরীক্ষা লাগে। Linux তার time_t-কে ৩২-বিট ARM প্ল্যাটফর্মে ৬৪-বিটে স্থানান্তর করেছে কার্নেল 5.6-এ (২০২০), সময়সীমার অনেক আগে।
Y2K38 মূল Y2K সমস্যা থেকে একটি গুরুত্বপূর্ণ দিক দিয়ে ভিন্ন। Y2K ছিল একটি ডেটা উপস্থাপনার সমস্যা — অনেক সিস্টেম বছরের জন্য মাত্র দুই ডিজিট রাখত, তাই ২০০০ দেখাত ১৯০০-র মতো — এবং এর জন্য কার্যত প্রতিটি প্রতিষ্ঠানে একসাথে সমন্বিত সফটওয়্যার হালনাগাদ দরকার ছিল। Y2K38 হলো নির্দিষ্ট কিছু সিস্টেমে একটি ডেটা-টাইপ ওভারফ্লো যেগুলো ৩২-বিট timestamp ব্যবহার করে, আর গত ১৫ বছরে লেখা আধুনিক সফটওয়্যার প্রায় নিশ্চিতভাবেই অপ্রভাবিত। ঝুঁকিটি সত্যিকারের, তবে সীমিত পরিসরে — এটিকে বৈশ্বিক সংকটের চেয়ে বরং লিগ্যাসি অবকাঠামো রক্ষণাবেক্ষণকারী দলগুলোর জন্য একটি লক্ষ্যভিত্তিক অডিট সমস্যা করে তোলে।
ISO 8601 এবং মানসম্মত তারিখ স্ট্রিংয়ের যুক্তি
ISO 8601 হলো সেই আন্তর্জাতিক মান, যা সংজ্ঞায়িত করে কীভাবে তারিখ ও সময়কে স্ট্রিং হিসেবে লিখতে হয়। আদর্শ রূপটি হলো YYYY-MM-DDTHH:MM:SS±HH:MM — হাইফেন দিয়ে আলাদা করা বছর, মাস ও দিন; তারিখ থেকে সময় আলাদা করতে একটি আক্ষরিক T অক্ষর; কোলন দিয়ে আলাদা করা ঘণ্টা, মিনিট ও সেকেন্ড; এবং +05:30-এর মতো একটি টাইমজোন অফসেট বা UTC বোঝাতে Z সাফিক্স। JavaScript-এর Date.toISOString() সবসময় এই ফরম্যাট মিলিসেকেন্ড ও একটি Z সাফিক্সসহ ফেরত দেয়: 2023-11-14T22:13:20.000Z।
ISO 8601-এর একমাত্র সবচেয়ে উপকারী বৈশিষ্ট্য হলো এটি লেক্সিকোগ্রাফিকভাবে সাজানো-যোগ্য: স্ট্রিংগুলোকে বর্ণানুক্রমে সাজালে সঠিক কালানুক্রমিক ক্রম তৈরি হয়। এই বৈশিষ্ট্যটি ISO 8601-কে ফাইল সিস্টেম, অবজেক্ট স্টোর ও ডেটাবেসে কী হিসেবে ব্যবহার করা নিরাপদ করে তোলে, যেখানে পার্স না করেই কালানুক্রমিক ক্রম চান। মানটি সংক্ষিপ্ত রূপও সংজ্ঞায়িত করে (শুধু তারিখের জন্য 20231114), সপ্তাহ নোটেশন (2024-W23-3 মানে ২০২৪-এর ২৩তম সপ্তাহের তৃতীয় দিন), এবং সময়কাল নোটেশন (P1Y2M3DT4H)। ইমেইল হেডারে ব্যবহৃত RFC 2822 ভিন্ন পথ নেয়: Mon, 03 Jun 2024 12:34:56 +0000 — মানুষের পাঠযোগ্য কিন্তু স্ট্রিং হিসেবে সাজানো যায় না এবং পার্স করা কষ্টকর।
MM/DD/YYYY (যুক্তরাষ্ট্রে প্রচলিত) এবং DD/MM/YYYY (ইউরোপে প্রচলিত)-এর মতো অঞ্চলভিত্তিক ফরম্যাটগুলো মৌলিকভাবেই দ্ব্যর্থক: 04/05/2024 স্ট্রিংটি এক প্রথায় ৫ এপ্রিল, অন্য প্রথায় ৪ মে বোঝায়। একটি পরিচিত লোকেলে শেষ ব্যবহারকারীদের দেখানোর জন্য এই ফরম্যাটগুলো ঠিক আছে, কিন্তু ডেটা সংরক্ষণ, লগ ফাইল, API পেলোড বা এমন যেকোনো প্রেক্ষাপটে যেখানে স্ট্রিংটি কোড বা ভিন্ন অঞ্চলের মানুষ পড়বে, সেখানে এগুলো কখনও ব্যবহার করা উচিত নয়। ISO 8601 দ্ব্যর্থতা পুরোপুরি দূর করে।
ডেটাবেসে টাইমজোন: সবসময় UTC-তে রাখুন, দেখানোর সময় রূপান্তর করুন
timestamp সংরক্ষণের সর্বজনীন সেরা চর্চা হলো সবসময় UTC-তে সংরক্ষণ করা এবং ব্যবহারকারীর জন্য রেন্ডার করার সময়ই কেবল স্থানীয় সময়ে রূপান্তর করা। কারণটি DST সীমার সেই মুহূর্তে স্পষ্ট হয় যাকে “fall back” বলা হয়: যখন US Eastern টাইমজোনের ঘড়ি ২:০০ AM থেকে ১:০০ AM-এ পিছিয়ে যায়, তখন স্থানীয় সময় ১:৩০ AM একই রাতে দুবার ঘটে। স্থানীয় সময় সংরক্ষণকারী সিস্টেমের কাছে অতিরিক্ত প্রেক্ষাপট ছাড়া প্রথম ১:৩০ AM-কে দ্বিতীয়টি থেকে আলাদা করার কোনো উপায় নেই। UTC-তে কোনো ডেলাইট সেভিং শিফট নেই, তাই দুটি মুহূর্তের UTC মান সম্পূর্ণ ভিন্ন এবং সবসময় দ্ব্যর্থহীন।
PostgreSQL দুটি আলাদা কলাম টাইপ দিয়ে এই পার্থক্যকে স্পষ্ট করে তোলে। TIMESTAMP WITH TIME ZONE (যা TIMESTAMPTZ-ও লেখা হয়) ইনপুটকে সংরক্ষণের সময় সবসময় UTC-তে রূপান্তর করে এবং পুনরুদ্ধারের সময় সেশন টাইমজোন পুনরায় প্রয়োগ করে — সারি ঢোকানোর সময় আপনি যে অফসেটই দিন না কেন। TIMESTAMP WITHOUT TIME ZONE আপনি যে স্ট্রিং দেন ঠিক সেটিই সংরক্ষণ করে, কোনো টাইমজোন সচেতনতা ছাড়াই। আপনি যদি 2024-03-10 02:30:00 একটি TIMESTAMP WITHOUT TIME ZONE কলামে ঢোকান, সেই আক্ষরিক মানটিই ফিরে আসে, যদিও সেই নির্দিষ্ট মুহূর্তটি US ঘড়িতে অস্তিত্বহীন কারণ এটি DST স্প্রিং-ফরওয়ার্ড ফাঁকের মধ্যে পড়ে। MySQL-এও একই বিভাজন আছে: TIMESTAMP UTC-তে স্বাভাবিক করে; DATETIME কোনো রূপান্তর ছাড়াই আক্ষরিক মান সংরক্ষণ করে।
ISO 8601 স্ট্রিংয়ে টাইমজোন তথ্য এনকোড করার সময়, স্থির UTC অফসেটের (-05:00) চেয়ে IANA টাইমজোন নাম (America/New_York, Europe/Berlin) পছন্দ করুন। একটি স্থির অফসেট শুধু একটি নির্দিষ্ট মুহূর্তে সঠিক; এটি এই বিষয়টি ধরতে পারে না যে America/New_York শীতে -05:00 এবং গ্রীষ্মে -04:00। Luxon, date-fns-tz এবং Python-এর zoneinfo মডিউলের মতো লাইব্রেরিগুলো যেকোনো মুহূর্তের সঠিক অফসেট নির্ধারণে IANA ডেটাবেস ব্যবহার করে, DST পরিবর্তন, ঐতিহাসিক অফসেট বদল ও ভবিষ্যৎ নিয়মের হালনাগাদ স্বয়ংক্রিয়ভাবে হিসাব করে।
প্রাইভেট, অফলাইন-সক্ষম এবং তাৎক্ষণিক
প্রতিটি রূপান্তর স্থানীয়ভাবে আপনার ব্রাউজারে চলে — কোনো সার্ভার নেই, কিছুই আপলোড হয় না, এবং কোনো নেটওয়ার্ক অনুরোধ করা হয় না। পেজটি একবার লোড হয়ে গেলে আপনি অফলাইনে থাকলেও কাজ করে। এটি বুকমার্ক করে রাখুন, যাতে পরের বার কোনো লগ ফাইল, API রেসপন্স, ডেটাবেস রেকর্ড বা JWT পেলোডে সন্দেহজনক দেখতে কোনো পূর্ণসংখ্যা পেলে এবং সেটি কোন তারিখ ও সময় বোঝায় তা জানার দরকার হলে দ্রুত অ্যাক্সেস পান।
Frequently asked questions
Unix time কী?
Unix time (যাকে epoch time বা POSIX time-ও বলা হয়) হলো ১ জানুয়ারি ১৯৭০-এর ০০:০০:০০ UTC — অর্থাৎ Unix epoch — থেকে অতিক্রান্ত সেকেন্ডের সংখ্যা। উদাহরণস্বরূপ, timestamp ১,৭০০,০০০,০০০ বোঝায় শনিবার, ১৪ নভেম্বর ২০২৩, ২২:১৩:২০ UTC। এটি একটি টাইমজোন-নিরপেক্ষ পূর্ণসংখ্যা, যা কার্যত প্রতিটি প্রোগ্রামিং ভাষা, ডেটাবেস ও API-তে দ্ব্যর্থতা ছাড়াই সময়ের মুহূর্ত উপস্থাপনে ব্যবহৃত হয়। এই কারণেই এটি '14-Nov-23 10:13 PM EST'-এর মতো ফরম্যাট স্ট্রিং প্রতিস্থাপন করেছে — বিভিন্ন অঞ্চলের সার্ভারে পূর্ণসংখ্যা দ্ব্যর্থহীন।
Unix epoch কী?
Unix epoch হলো Unix time-এর রেফারেন্স পয়েন্ট: Coordinated Universal Time (UTC)-তে ১ জানুয়ারি ১৯৭০-এর শুরুর মধ্যরাত। প্রতিটি Unix timestamp সেই মুহূর্ত থেকে সেকেন্ড (বা মিলিসেকেন্ড, বা মাইক্রোসেকেন্ড) গণনা করে। epoch-এর আগের timestamp ঋণাত্মক — Unix timestamp −৮৬,৪০০ বোঝায় ৩১ ডিসেম্বর ১৯৬৯, ০০:০০:০০ UTC। ১৯৭০ বেছে নেওয়াটা ছিল বাস্তবসম্মত: এটি সেই বছর যখন Unix প্রথম বিতরণ করা হয়, তাই প্রকৌশলীরা বর্তমান তারিখকে একটি সুবিধাজনক শূন্য বিন্দু হিসেবে ব্যবহার করেছিলেন।
UNIX_TIMESTAMP কী করে?
MySQL ও MariaDB-তে, কোনো আর্গুমেন্ট ছাড়া UNIX_TIMESTAMP() বর্তমান তারিখ ও সময়কে সেকেন্ড-নির্ভুলতার Unix timestamp হিসেবে ফেরত দেয়। একটি তারিখ আর্গুমেন্টসহ — UNIX_TIMESTAMP('2024-01-01 00:00:00') — এটি একটি datetime স্ট্রিংকে তার Unix timestamp-এ রূপান্তর করে। এর বিপরীত হলো FROM_UNIXTIME(ts), যা একটি timestamp-কে আবার মানুষের পাঠযোগ্য datetime-এ ফেরায়। PostgreSQL-এ সমতুল্য হলো timestamp পেতে EXTRACT(EPOCH FROM NOW()) এবং ফিরে রূপান্তরে TO_TIMESTAMP(ts)। এই ওয়েব টুলটি কোনো ডেটাবেস সংযোগ ছাড়াই একই রূপান্তর করে।
Unix timestamp কেন ব্যবহার করা হয়?
Unix timestamp তিনটি কারণে জনপ্রিয়: এগুলো টাইমজোন-নিরপেক্ষ (সবসময় UTC থেকে পরিমাপ করা), এগুলো সরল পূর্ণসংখ্যা তাই সংরক্ষণ, তুলনা ও গাণিতিক হিসাব সস্তা, এবং এগুলো প্রতিটি OS ও ভাষায় সর্বজনীন। ডেটাবেসে ১,৭০০,০০০,০০০ সংরক্ষণ করা দ্ব্যর্থহীন; '14 Nov 2023 10:13 PM' সংরক্ষণ করলে টাইমজোন ও ফরম্যাট নিয়ে প্রশ্ন থেকে যায়, যা বিভিন্ন অঞ্চলের সার্ভারে সূক্ষ্ম বাগ তৈরি করে। timestamp দিয়ে সাজানোও সহজ — বড় সংখ্যা মানে সবসময় পরের সময়।
Unix timestamp ফরম্যাটের একটি উদাহরণ কী?
১ জানুয়ারি ২০২৪, ০০:০০:০০ UTC-র জন্য সেকেন্ডে Unix timestamp: 1704067200 (১০ ডিজিট)। মিলিসেকেন্ডে: 1704067200000 (১৩ ডিজিট)। মাইক্রোসেকেন্ডে: 1704067200000000 (১৬ ডিজিট)। JavaScript-এ, Date.now() মিলিসেকেন্ড ফেরত দেয়; Unix শেলে, date +%s সেকেন্ড ফেরত দেয়। Python-এ: import time; int(time.time()) সেকেন্ড দেয়; int(time.time() * 1000) মিলিসেকেন্ড দেয়। epochconverter.com একই রূপান্তর দেখায়, কিন্তু স্কেল স্বয়ংক্রিয়ভাবে শনাক্ত করে না — সেকেন্ড বনাম ms নিজে হাতে বেছে নিতে হয়।
Unix time-এ ১ ঘণ্টা কত?
Unix time-এ এক ঘণ্টা ঠিক ৩,৬০০ সেকেন্ড, বা ৩,৬০০,০০০ মিলিসেকেন্ড। এক দিন ৮৬,৪০০ সেকেন্ড। এক সপ্তাহ ৬০৪,৮০০ সেকেন্ড। এক বছর (৩৬৫ দিন) ৩১,৫৩৬,০০০ সেকেন্ড। এখন থেকে এক ঘণ্টা পরের timestamp বের করতে বর্তমান সেকেন্ড timestamp-এর সাথে ৩,৬০০ যোগ করুন। এই গাণিতিক হিসাবই timestamp-কে এত উপকারী করে তোলে — সরল সময় গণনার জন্য কোনো ডেট লাইব্রেরির দরকার নেই, শুধু যোগ ও বিয়োগ।
সেকেন্ড ও মিলিসেকেন্ড timestamp-এর মধ্যে পার্থক্য কী?
একটি সেকেন্ড-নির্ভুলতার Unix timestamp-এ ২০০১ থেকে ২২৮৬-এর মধ্যকার তারিখের জন্য ১০টি ডিজিট থাকে — যেমন 1700000000। একটি মিলিসেকেন্ড timestamp সেই সংখ্যার ১,০০০ গুণ, যা ১৩ ডিজিট দেয়: 1700000000000। JavaScript-এর Date.now() মিলিসেকেন্ড ফেরত দেয়; বেশিরভাগ সার্ভার ভাষা ডিফল্টভাবে সেকেন্ড ব্যবহার করে। এই কনভার্টার ডিজিট সংখ্যা দিয়ে এককটি স্বয়ংক্রিয়ভাবে শনাক্ত করে (১০ → সেকেন্ড, ১৩ → মিলিসেকেন্ড, ১৬+ → মাইক্রোসেকেন্ড), তবে আপনি একটি নির্দিষ্ট একক জোরও করতে পারেন। epochconverter.com ও unixtimestamp.com স্বয়ংক্রিয়ভাবে শনাক্ত করে না — আপনাকে আগেভাগেই স্কেল জানতে হয়।
১৬ বা ১৭ ডিজিটের timestamp কী?
১৬ ও ১৭ ডিজিটের timestamp মাইক্রোসেকেন্ড (সেকেন্ডের দশ লক্ষ ভাগের এক ভাগ) বোঝায়। এগুলো উচ্চ-ফ্রিকোয়েন্সি ট্রেডিং সিস্টেম, হার্ডওয়্যার সেন্সর, Zipkin ও Jaeger-এর মতো ডিস্ট্রিবিউটেড ট্রেসিং টুল, এবং Cassandra-র মতো কিছু ডেটাবেসে সাধারণ। 1700000000000000-এর মতো একটি ১৬-ডিজিট মান হলো সেকেন্ড timestamp-কে ১,০০০,০০০ দিয়ে গুণ করা। এই কনভার্টার ১৬-ডিজিট ইনপুটকে মাইক্রোসেকেন্ড হিসেবে শনাক্ত করে এবং সঠিকভাবে মানুষের পাঠযোগ্য তারিখে রূপান্তর করে — একটি বিশেষ ক্ষেত্র যা বেশিরভাগ সাধারণ epoch টুল বাদ দেয়।
Discord timestamp ট্যাগ কীভাবে তৈরি করব?
Discord মেসেজে Unix timestamp রেন্ডার করে <t:UNIX_SECONDS:FORMAT_CODE> সিনট্যাক্স দিয়ে। সাতটি ফরম্যাট কোড হলো: t (সংক্ষিপ্ত সময়, যেমন 10:13 PM), T (দীর্ঘ সময়, 10:13:20 PM), d (সংক্ষিপ্ত তারিখ, 11/14/2023), D (দীর্ঘ তারিখ, November 14, 2023), f (সংক্ষিপ্ত তারিখ/সময় — ডিফল্ট), F (সপ্তাহের দিনসহ দীর্ঘ তারিখ/সময়), এবং R (আপেক্ষিক, যেমন '2 years ago')। উদাহরণ: <t:1700000000:F> প্রতিটি পাঠকের স্থানীয় টাইমজোনে 'Saturday, November 14, 2023 10:13 PM' দেখায়। বেশিরভাগ Discord timestamp জেনারেটর মাত্র এক বা দুটি কোড তৈরি করে — এই টুল প্রিভিউসহ সাতটিই একসাথে তৈরি করে।
ISO 8601 ফরম্যাট কী?
ISO 8601 হলো তারিখ ও সময়কে মেশিন-পাঠযোগ্য, সাজানো-যোগ্য ফরম্যাটে উপস্থাপনের আন্তর্জাতিক মান। একটি পূর্ণ ISO 8601 datetime দেখতে হয় 2023-11-14T22:13:20.000Z-এর মতো — প্রথমে YYYY-MM-DD রূপে তারিখ, তারপর বিভাজক হিসেবে 'T', তারপর HH:MM:SS.mmm, তারপর UTC বোঝাতে 'Z'। JavaScript-এর Date.toISOString() সবসময় এই ফরম্যাট ফেরত দেয়। এটি JSON API, লগ ফাইল ও ডেটাবেসের জন্য নিরাপদ ডিফল্ট, কারণ এটি যেকোনো লোকেল বা টাইমজোনে দ্ব্যর্থহীন এবং স্ট্রিং হিসেবে সঠিকভাবে সাজানো যায়।
Python-এ একটি timestamp কীভাবে রূপান্তর করব?
datetime মডিউল ব্যবহার করুন। একটি Unix timestamp-কে UTC-তে রূপান্তর করতে: from datetime import datetime, timezone; dt = datetime.fromtimestamp(1700000000, tz=timezone.utc)। বর্তমান সেকেন্ড timestamp পেতে: import time; ts = int(time.time())। মিলিসেকেন্ডের জন্য: ts_ms = int(time.time() * 1000)। আপনার লোকাল মেশিনের টাইমজোন সেটিং থেকে দ্ব্যর্থতা এড়াতে fromtimestamp()-এ সবসময় tz=timezone.utc দিন — এটি না দিলে Python সার্ভারের লোকাল টাইমজোন ব্যবহার করে, যা ভিন্ন মেশিনে বাগ তৈরি করে।
Year 2038 সমস্যা কী?
১৯ জানুয়ারি ২০৩৮-এর ০৩:১৪:০৭ UTC-তে, ৩২-বিট সাইনড Unix timestamp উপচে যায় — ২³¹ − ১ (২,১৪৭,৪৮৩,৬৪৭)-এ পৌঁছে একটি বড় ঋণাত্মক সংখ্যায় গড়িয়ে যায়, তারিখগুলোকে ১৯০১ হিসেবে ভুলভাবে দেখায়। যেসব সিস্টেম timestamp-কে ৩২-বিট পূর্ণসংখ্যা হিসেবে রাখে — পুরনো Linux কার্নেল, কিছু এমবেডেড ফার্মওয়্যার, ৩২-বিট বিল্ডে MySQL — সেগুলো ঝুঁকিতে আছে। ৬৪-বিট timestamp আরও ২৯২ বিলিয়ন বছর পর্যন্ত উপচে যায় না। বেশিরভাগ আধুনিক সফটওয়্যার ইতিমধ্যে ৬৪-বিট পূর্ণসংখ্যা ব্যবহার করে, তবে লিগ্যাসি এমবেডেড কোড ও পুরনো ডেটাবেস স্কিমা এখনও অডিট করা দরকার।
এই কনভার্টার কি অফলাইনে কাজ করে?
হ্যাঁ — প্রতিটি রূপান্তর আপনার ডিভাইসের ঘড়ি ও JavaScript-এর অন্তর্নির্মিত Date API ব্যবহার করে স্থানীয়ভাবে আপনার ব্রাউজারে চলে। কোনো নেটওয়ার্ক অনুরোধ নেই, কোনো সার্ভার কল নেই, এবং কিছুই আপলোড হয় না। পেজটি একবার লোড হয়ে গেলে আপনি অফলাইনে গেলেও কাজ করে, যা সীমিত ইন্টারনেট অ্যাক্সেসের পরিবেশে এটিকে নির্ভরযোগ্য করে তোলে। ডেস্কটপ epoch টুলের বিপরীতে এখানে অ্যাকাউন্ট তৈরি বা কিছু ইনস্টল করার দরকার নেই।
timestamp কেন UTC ব্যবহার করে?
UTC (Coordinated Universal Time) হলো বৈশ্বিক সময় মান, যাতে কোনো ডেলাইট-সেভিং অফসেট নেই এবং কোনো আঞ্চলিক টাইমজোন সমন্বয় নেই। UTC-তে সময় সংরক্ষণ করার মানে বিভিন্ন দেশের দুটি সার্ভার সবসময় একমত থাকে একটি timestamp-এর অর্থ কী, আর আপনি শুধু দেখানোর সময়েই যেকোনো স্থানীয় টাইমজোনে রূপান্তর করেন। স্থানীয় সময় (যেমন '10 PM Eastern') সংরক্ষণ ভঙ্গুর: DST-র জন্য ঘড়ি বদলালে, ব্যবহারকারী টাইমজোনের মধ্যে সরে গেলে, বা লগ ফাইল যেখানে পড়া হয় তার থেকে ভিন্ন অঞ্চলের সার্ভারে লেখা হলে এটি ভেঙে পড়ে।
Related tools
সব টুল দেখুন
নতুন অ্যাসপেক্ট রেশিও ক্যালকুলেটর
একটি অনুপাত লক করুন এবং নতুন সাইজের জন্য অনুপস্থিত প্রস্থ বা উচ্চতা বের করুন।
নতুন সংখ্যা থেকে শব্দ
যেকোনো সংখ্যাকে ইংরেজি শব্দে লিখুন, চেকের জন্য একটি মুদ্রা মোড সহ।
নতুন সময়কাল ক্যালকুলেটর
দুটি ঘড়ির সময়ের মধ্যেকার সময় বের করুন এবং একাধিক সময়কাল যোগ করুন।
নতুন টাইম জোন কনভার্টার
বিভিন্ন শহরের সময় তুলনা করুন এবং সবার জন্য সুবিধাজনক মিটিং পরিকল্পনা করুন।
নতুন Currency Converter
Convert between 30+ world currencies with recent reference rates — fully in your browser.
নতুন Scientific Calculator
Full scientific calculator with trig, log, factorial, powers and memory functions.