ইউনিক্স টাইমস্ট্যাম্প কনভার্টার

ইউনিক্স টাইমস্ট্যাম্প কোনো ঝামেলা ছাড়াই

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

ইউনিক্স টাইম আসলে কী

একটি ইউনিক্স টাইমস্ট্যাম্প হলো 1 জানুয়ারি 1970-এর 00:00:00 UTC থেকে অতিবাহিত সেকেন্ডের সংখ্যা, লিপ সেকেন্ড গণনা না করে। সেই মুহূর্তটিকে ইপক বলা হয়, এবং এটি প্রাথমিক ইউনিক্স ইঞ্জিনিয়াররা বেছে নিয়েছিলেন শুধু কারণ এটি গণনা শুরু করার জন্য একটি সুবিধাজনক গোলাকার তারিখ ছিল। ইপকে মানটি ঠিক 0। তারপর থেকে প্রতিটি সেকেন্ড এক যোগ করে, তাই সংখ্যাটি শুধু বাড়ে। 1970-এর আগের তারিখগুলোও পুরোপুরি বৈধ, নেগেটিভ পূর্ণসংখ্যা হিসেবে প্রকাশ করা হয়।

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

সেকেন্ড, মিলিসেকেন্ড, ও সহযোগী

ক্লাসিক ইউনিক্স টাইম সম্পূর্ণ সেকেন্ড গণনা করে, যা আজ আপনি যে পরিচিত দশ-অঙ্কের সংখ্যা দেখেন তা দেয়। কিন্তু অনেক পরিবেশে সূক্ষ্ম রেজোলিউশন প্রয়োজন। JavaScript, উদাহরণস্বরূপ, মিলিসেকেন্ডে কাজ করে, একটি তেরো-অঙ্কের মান তৈরি করে, এবং কিছু সিস্টেম আরও এগিয়ে মাইক্রোসেকেন্ড বা ন্যানোসেকেন্ডে যায়। একটি নির্ভরযোগ্য অভিজ্ঞতা নিয়ম: একটি দশ-অঙ্কের সংখ্যা হলো সেকেন্ড, তেরো অঙ্ক হলো মিলিসেকেন্ড। যদি আপনার রূপান্তরিত তারিখ কোথাও 1970-এর কাছাকাছি নেমে যায় যেখানে আপনি বর্তমান দিন প্রত্যাশা করছিলেন, আপনি প্রায় নিশ্চিতভাবে একটি সেকেন্ড ফিল্ডে মিলিসেকেন্ড দিয়েছেন, বা উল্টো। আমাদের কনভার্টার মাত্রা স্বয়ংক্রিয়ভাবে সনাক্ত করে তাই আপনাকে খুব কমই অনুমান করতে হয়।

কেন ডেভেলপাররা এর উপর নির্ভর করে

বড় জয়টি হলো একটি টাইমস্ট্যাম্প টাইমজোন-নিরপেক্ষ। পূর্ণসংখ্যা 1735689600 টোকিও, বার্লিন, ও সাও পাওলোতে একই মুহূর্তকে নির্দেশ করে। একটি ফরম্যাট করা লোকাল স্ট্রিংয়ের বদলে সেই সংখ্যাটি সংরক্ষণ করা মানে আপনাকে কখনো ভাবতে হবে না একটি মান কোন ঘড়ির অন্তর্গত ছিল। সাজানোও তুচ্ছ, কারণ কালানুক্রমিক ক্রম শুধু সাংখ্যিক ক্রম, তাই একটি টাইমস্ট্যাম্প কলামের উপর একটি ডেটাবেস ইনডেক্স কোনো পার্সিং ছাড়াই ঘটনাগুলো সঠিকভাবে সাজায়। গণিতও সমানভাবে পরিষ্কার: দুটি ঘটনার মধ্যে ব্যবধান একটি বিয়োগ, এবং একটি দিন যোগ করা মানে 86400 যোগ করা। এই বৈশিষ্ট্যগুলোই ঠিক কেন লগ, টোকেন, ক্যাশ, ও মেসেজ কিউ সবাই ইপক টাইমের দিকে যায়।

উভয় দিকে রূপান্তর

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

UTC বনাম লোকাল সময়, ক্লাসিক ফাঁদ

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

2038 সালের সমস্যা

অনেক পুরনো সিস্টেম ইউনিক্স টাইমকে একটি সাইনড 32-বিট পূর্ণসংখ্যায় সংরক্ষণ করত। সেই ফিল্ডটি 19 জানুয়ারি 2038-এর 03:14:07 UTC-এর এক সেকেন্ড পরে জায়গা শেষ করে, যখন কাউন্টারটি ওভারফ্লো হয় এবং একটি নেগেটিভ সংখ্যায় ঘুরে যায়, সম্ভাব্যভাবে তারিখগুলোকে 1901-এ ফিরিয়ে দেয়। এটি Y2K-এর মতো একই পরিবারের সমস্যা। ভালো খবর হলো আধুনিক অপারেটিং সিস্টেম ও ভাষাগুলো মূলত 64-বিট টাইমস্ট্যাম্পে চলে গেছে, যা প্রায় 292 বিলিয়ন বছরের জন্য ওভারফ্লো হবে না, তাই নতুন কোডের জন্য এটি বেশিরভাগ একটি জরুরি অবস্থার বদলে জানার মতো একটি ঐতিহাসিক কৌতূহল।

আরও ব্রাউজার-ভিত্তিক সহায়কের জন্য আমাদের ডেভেলপার টুল দেখুন, এবং যদি আপনার সংখ্যাগুলো নিয়ে কাজ করতে হয়, ক্যালকুলেটর এক ক্লিক দূরে।

প্রায়শই জিজ্ঞাসিত প্রশ্ন