Unix Timestamp: এটি কী, রূপান্তর এবং মোবাইল ডেভেলপমেন্টে সংরক্ষণ

Unix Timestamp কী?

Unix Timestamp (POSIX time, Epoch time বা Unix time নামেও পরিচিত) একটি সময় পরিমাপ পদ্ধতি যা 1 জানুয়ারি 1970 00:00:00 UTC (Unix যুগ) থেকে অতিক্রান্ত সেকেন্ডের সংখ্যা নির্ধারণ করে। এই তারিখটি Unix অপারেটিং সিস্টেমের জন্য শুরুর বিন্দু হিসেবে নির্বাচিত হয়েছিল এবং পরবর্তীতে বিন্যাসটি কম্পিউটিং সিস্টেমে সময় উপস্থাপনের জন্য ডি ফ্যাক্টো স্ট্যান্ডার্ডে পরিণত হয়। Timestamp লিপ সেকেন্ড বিবেচনা করে না — প্রতিটি মিনিট 60 সেকেন্ড হিসেবে গণনা করা হয়, যদিও আন্তর্জাতিক পৃথিবী ঘূর্ণন পরিষেবা মাঝে মাঝে পারমাণবিক সময় সংশোধনের জন্য একটি অতিরিক্ত সেকেন্ড যোগ করে।

Unix যুগ: কেন 1970?

1 জানুয়ারি 1970-এর নির্বাচন Unix অপারেটিং সিস্টেমের ইতিহাসের সাথে সম্পর্কিত। ডেভেলপার Ken Thompson এবং Dennis Ritchie এই তারিখটিকে একটি সরল গোলাকার শুরুর বিন্দু হিসেবে বেছে নেন — এটি সমস্ত সম্ভাব্য তারিখ অন্তর্ভুক্ত করার জন্য যথেষ্ট প্রাথমিক ছিল এবং সময়কে 32-বিট সাইনড পূর্ণসংখ্যায় সংরক্ষণ করার জন্য যথেষ্ট দেরীও ছিল। প্রাথমিকভাবে, সময় সেকেন্ডের ষাট ভাগে মাপা হত, তারপর টিকে (1/60 সেকেন্ড), এবং শুধুমাত্র Unix-এর সপ্তম সংস্করণে (V7, 1979) বিন্যাসটি সেকেন্ডের পূর্ণ সংখ্যা হিসেবে স্থিতিশীল হয়। The Open Group Base Specifications (Issue 8, 2024) অনুসারে, POSIX-সঙ্গত সিস্টেমগুলির জন্য এই বিন্যাস সমর্থন করা বাধ্যতামূলক।

Unix Timestamp কিভাবে কাজ করে

Unix Timestamp-এর কাজের নীতি একটি সরল কাউন্টারের ওপর ভিত্তি করে: প্রতিটি অতিবাহিত দিন মানতে 86,400 সেকেন্ড যোগ করে। উদাহরণস্বরূপ, timestamp 1,720,000,000 মধ্য 2024-এর একটি তারিখের সাথে মিলে যায় — সঠিক রূপান্তর একটি দিন, ঘন্টা এবং মিনিটে সেকেন্ডের সংখ্যা দিয়ে ভাগ করে করা যেতে পারে। এই পদ্ধতি timestamp-কে মেশিন সংরক্ষণের জন্য আদর্শ করে তোলে: এটি একটি পূর্ণসংখ্যা যা 4 বাইট (32-বিট int) বা 8 বাইট (64-বিট long) নেয় এবং সরাসরি তুলনা সমর্থন করে — বড় timestamp = পরবর্তী তারিখ।

রূপান্তর গণিত

এক দিন = 86,400 সেকেন্ড (24 x 60 x 60)। এক ঘন্টা = 3,600 সেকেন্ড। Timestamp কে তারিখে রূপান্তর করতে, যুগ থেকে দিন, ঘন্টা, মিনিট এবং সেকেন্ডের সংখ্যা ক্রমান্বয়ে গণনা করতে হবে। বিপরীত রূপান্তর — তারিখকে 1970-01-01 থেকে দিনে রূপান্তর করুন, তারপর 86,400 দিয়ে গুণ করুন এবং UTC অফসেট যোগ করুন। Java এবং Kotlin-এ, এই গণনাগুলি ইতিমধ্যে স্ট্যান্ডার্ড ক্লাস java.time.Instant এবং java.util.Date-এ বাস্তবায়িত, যা ডেভেলপারকে ম্যানুয়াল গণনা থেকে রক্ষা করে।

        // Unix Timestamp সেকেন্ডে পান
val seconds = System.currentTimeMillis() / 1000

// java.time-এর মাধ্যমে timestamp কে তারিখে রূপান্তর করুন
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// বিপরীত: তারিখ থেকে timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Unix Timestamp কে তারিখে রূপান্তর এবং বিপরীত

Unix Timestamp-কে মানব-পঠনযোগ্য তারিখে রূপান্তর করা মোবাইল ডেভেলপমেন্টের সবচেয়ে সাধারণ অপারেশনগুলির মধ্যে একটি। Android-এ, ন্যূনতম API সংস্করণের ওপর নির্ভর করে বেশ কয়েকটি রূপান্তর পদ্ধতি উপলব্ধ: API 26+-এর জন্য java.time.Instant ব্যবহার করার পরামর্শ দেওয়া হয়, পুরানো সংস্করণগুলির জন্য java.util.Date এবং java.text.SimpleDateFormat ব্যবহার করা হয়। এটি মনে রাখা গুরুত্বপূর্ণ যে Android এবং JVM ডিফল্টভাবে সেকেন্ড নয়, মিলিসেকেন্ড ব্যবহার করে — যদি timestamp সার্ভার থেকে সেকেন্ডে প্রাপ্ত হয়, তবে স্ট্যান্ডার্ড কনস্ট্রাক্টরে পাস করার আগে এটিকে 1000 দিয়ে গুণ করতে হবে।

টাইমজোন-সচেতন রূপান্তর

Unix Timestamp-এর প্রধান সুবিধাগুলির মধ্যে একটি হল অবস্থান স্বাধীনতা। সার্ভার সর্বদা UTC-তে timestamp ফেরত দেয় এবং স্থানীয় তারিখ ও সময়ে রূপান্তর ক্লায়েন্ট পাশে সঞ্চালিত হয়। Kotlin-এ, উপযুক্ত ZoneId সহ ZonedDateTime ব্যবহার করা হয় — হয় সিস্টেম বা ব্যবহারকারী-নির্বাচিত। যদি একটি অ্যাপ্লিকেশন বিভিন্ন টাইমজোনে সময় দেখায় (উদাহরণস্বরূপ, ভ্রমণকারীদের জন্য), timestamp সার্ভার থেকে টাইমজোন পাস করার প্রয়োজনীয়তা দূর করে — একটি একক সময় চিহ্ন যথেষ্ট।

// ব্যবহারকারী টাইমজোন সহ রূপান্তর
fun formatTimestamp(seconds: Long, zoneId: ZoneId): String {
    val instant = Instant.ofEpochSecond(seconds)
    val formatter = DateTimeFormatter
        .ofPattern("dd.MM.yyyy HH:mm:ss")
    return formatter.format(instant.atZone(zoneId))
}

// উদাহরণ: timestamp = 1720000000, zone = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

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

2038 সালের সমস্যা (Y2K38) হল Unix Timestamp-কে 32-বিট সাইনড পূর্ণসংখ্যা হিসেবে সংরক্ষণের একটি মৌলিক সীমাবদ্ধতা। 32-বিট সাইনড int-এর সর্বোচ্চ মান 2,147,483,647, যা 19 জানুয়ারি 2038 03:14:07 UTC-র সাথে মিলে যায়। এই তারিখের পরে, মানটি ওভারফ্লো হয়ে একটি ঋণাত্মক সংখ্যায় পরিণত হয়, যা 32-বিট time_t ব্যবহারকারী সিস্টেমে ব্যর্থতা সৃষ্টি করে। সমস্যাটি সুপরিচিত Y2K-এর মতো, তবে এটি প্রাথমিকভাবে এম্বেডেড সিস্টেম, পুরানো Android সংস্করণ এবং 32-বিট আর্কিটেকচারের IoT ডিভাইসগুলিকে প্রভাবিত করে।

সমস্যার মাত্রা

Linux Foundation (2025) অনুসারে, শিল্প এবং IoT বিভাগে প্রায় 15% Linux ডিভাইস এখনও 32-বিট বিল্ড ব্যবহার করে। Android ডিভাইসগুলির জন্য, ঝুঁকি কম — বেশিরভাগ আধুনিক স্মার্টফোন 64-বিট প্রসেসরে (ARM64) চলে, কিন্তু Android 4.x এবং নিম্ন সংস্করণের পুরানো মডেলগুলি 32-বিট time_t ব্যবহার করতে পারে। সমাধান হল 64-বিট time-তে স্থানান্তর, যা 292 বিলিয়ন বছর পর্যন্ত নিরাপদ। Android 5.0 (API 21) থেকে শুরু করে, সমস্ত ডিভাইস কার্নেল স্তরে 64-বিট সময় ব্যবহার করে। মোবাইল অ্যাপ্লিকেশন ডেভেলপারদের শুধু timestamp কে Long (64-বিট) টাইপে সংরক্ষণ করতে হবে অ্যাপ্লিকেশন স্তরে সমস্যা এড়াতে।

Android-এ Unix Timestamp নিয়ে কাজ

Android ডেভেলপমেন্টে, Unix Timestamp-এর সঠিক ব্যবস্থাপনা ডেটা সিঙ্ক্রোনাইজেশন, বার্তা গ্রহণের সময় প্রদর্শন, টাইমআউট গণনা এবং বিজ্ঞপ্তি নির্ধারণের জন্য গুরুত্বপূর্ণ। সিস্টেম কল System.currentTimeMillis() Unix যুগ থেকে মিলিসেকেন্ডে বর্তমান সময় ফেরত দেয় — এটি ডিভাইসে উপলব্ধ সবচেয়ে সঠিক সময় উৎস। নেটওয়ার্ক অনুরোধের জন্য, সাধারণত সেকেন্ডে Unix Timestamp ব্যবহার করা হয়, কারণ বেশিরভাগ REST API এবং ডাটাবেস সেকেন্ডে কাজ করে।

প্রস্তাবিত অনুশীলন

কখনও ব্যবধান মাপার জন্য System.currentTimeMillis() ব্যবহার করবেন না — এই উদ্দেশ্যে System.nanoTime() রয়েছে, যা মোনোটোনিক এবং ব্যবহারকারীর ঘড়ি পরিবর্তন দ্বারা প্রভাবিত হয় না। সময় প্রদর্শনের জন্য, সর্বদা timestamp UTC-তে সংরক্ষণ করুন এবং UI পাশে স্থানীয় টাইমজোনে রূপান্তর করুন। ডাটাবেসের (SQLite, Room) সাথে কাজ করার সময়, INTEGER টাইপ ব্যবহার করুন এবং timestamp সেকেন্ডে সংরক্ষণ করুন — এটি 8 বাইট (Long) নেয় এবং নেটিভ SQL বাছাই সমর্থন করে। JSON সিরিয়ালাইজেশনের জন্য, timestamp কে স্ট্রিংয়ের পরিবর্তে সংখ্যা (Long) হিসেবে পাঠানোর পরামর্শ দেওয়া হয় — এটি বেশি কম্প্যাক্ট এবং দ্রুত পার্স হয়।

// সঠিক নির্বাহ সময় পরিমাপ
val start = System.nanoTime()
// ... অপারেশন ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Room (Entity) এ সংরক্ষণ করুন
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // সেকেন্ডে Unix Timestamp
)

সার্ভার সময় ব্যবস্থাপনা

সার্ভার থেকে Unix Timestamp গ্রহণ করার সময়, সর্বদা পরিমাপের একক পরীক্ষা করুন: কিছু API মিলিসেকেন্ড ফেরত দেয় (JavaScript-সঙ্গত), অন্যগুলি সেকেন্ড ফেরত দেয় (POSIX মান)। এককগুলির চুক্তি API ডকুমেন্টেশনে নথিভুক্ত করা উচিত। সার্ভার প্রতিক্রিয়ায়, timestamp Long (JSON সংখ্যা) বা String (ISO 8601) হিসেবে পাস করা যেতে পারে। ডিবাগিংয়ের জন্য, একটি ইউটিলিটি ফাংশন যোগ করুন যা timestamp কে মানব-পঠনযোগ্য বিন্যাসে আউটপুট করে — এটি ডেভেলপমেন্টের সময় সময় চিহ্নগুলির সঠিকতা যাচাই সহজ করে।

ডাটাবেসে সময় চিহ্ন সংরক্ষণ

ডাটাবেসে সময় সংরক্ষণ বিন্যাসের পছন্দ সরাসরি কুয়েরি কর্মক্ষমতা, কোড জটিলতা এবং টাইমজোন ব্যবস্থাপনার সঠিকতাকে প্রভাবিত করে। Unix Timestamp রিলেশনাল ডাটাবেসের জন্য সবচেয়ে কার্যকর বিন্যাস: এটি একটি পূর্ণসংখ্যা (4 বা 8 বাইট) হিসেবে সংরক্ষিত হয়, ইনডেক্সিং সমর্থন করে এবং দ্রুত বাছাই সক্ষম করে। ISO 8601 স্ট্রিংয়ের বিপরীতে, timestamp বাছাইয়ের জন্য পার্সিং প্রয়োজন হয় না এবং ইনডেক্সে কম জায়গা নেয়। Room এবং SQLite-এর জন্য, timestamp কে INTEGER হিসেবে সংরক্ষণ এবং সময় কলামে একটি ইনডেক্স ব্যবহার করার পরামর্শ দেওয়া হয়।

মোবাইল প্রকল্পের জন্য সুপারিশ

Room লাইব্রেরি ব্যবহারকারী Android অ্যাপ্লিকেশনের জন্য, timestamps কে Long (64-বিট) হিসেবে সংরক্ষণ এবং Long ও Date বা Instant-এর মধ্যে স্বয়ংক্রিয় রূপান্তরের জন্য TypeConverter ব্যবহার করার পরামর্শ দেওয়া হয়। ডাটাবেসে কুয়েরি করার সময়, তুলনা অপারেটর (>, <, BETWEEN) ব্যবহার করুন — এগুলি পূর্ণসংখ্যা টাইপের সাথে নেটিভভাবে কাজ করে। সময়-ভিত্তিক বাছাই প্রয়োজন এমন ডেটা ক্যাশ করার জন্য (যেমন বার্তা তালিকা), সর্বদা timestamp কলামে একটি ইনডেক্স তৈরি করুন — এটি বড় ডেটা ভলিউমের সাথে ORDER BY কুয়েরিগুলিকে কয়েকগুণ দ্রুত করবে।