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_t में स्थानांतरण है, जो 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 वाली क्वेरी को कई गुना तेज़ करेगा।