Unix टाइमस्टॅम्पचे तारखेत रूपांतर

Unix timestamp म्हणजे काय?

Unix timestamp (याला Unix time किंवा POSIX time असेही म्हणतात) म्हणजे 1970-01-01 00:00:00 UTC पासून — ज्याला Unix epoch म्हणतात — किती सेकंद गेले आहेत याची संख्या. संगणक क्षेत्रात हा एक मोठ्या प्रमाणावर वापरला जाणारा मानक आहे, कारण तो वेळेचा एक क्षण एका single integer मध्ये दाखवतो. त्यामुळे स्टोरेज, तुलना (comparison) आणि गणित (arithmetic) सोपे होते.

JavaScript मध्ये वेळ अंतर्गत (internally) milliseconds मध्ये हाताळली जाते, त्यामुळे Date.now() हा Unix timestamp 1000 ने गुणाकार केलेला परत करतो. अनेक APIs, databases आणि backend systems मात्र seconds वापरतात. हे tool दोन्ही formats स्वीकारते आणि तुम्ही दिलेल्या संख्येच्या आकारावरून seconds किंवा milliseconds आहे का ते आपोआप ओळखते.

लक्षात ठेवण्यासारखे Unix timestamps

Timestamp	Date (UTC)	Note
0	1970-01-01 00:00:00	Unix epoch
1,000,000,000	2001-09-09 01:46:40	1 billion seconds
2,000,000,000	2033-05-18 03:33:20	2 billion seconds
2,147,483,647	2038-01-19 03:14:07	Year 2038 problem (max 32-bit)

1970च का?

1 जानेवारी 1970 हा Unix epoch काही प्रमाणात परंपरेमुळे (convention) आणि काही प्रमाणात व्यावहारिक मर्यादांमुळे निवडला गेला. Unix ची निर्मिती 1960च्या शेवटी आणि 1970च्या सुरुवातीला Bell Labs मध्ये झाली. वेळ सादर करण्यासाठी एक अलीकडची (recent), “गोल” सुरुवातीची तारीख लागली. 1 जानेवारी 1970 ही व्यावहारिकदृष्ट्या पुरेशी अलीकडची होती आणि तिला खास तांत्रिक महत्त्व नव्हते — ती फक्त सोयीस्कर anchor date होती.

इतर सिस्टम्समध्ये वेगवेगळे epoch असतात: Windows FILETIME epoch 1 जानेवारी 1601; GPS time 6 जानेवारी 1980 पासून; NTP epoch 1 जानेवारी 1900. सिस्टम्समध्ये रूपांतरण (conversion) करताना प्रत्येक सिस्टमचा epoch माहित असणे महत्त्वाचे आहे.

Seconds vs milliseconds

मूळ Unix timestamp seconds मध्ये असतो. बहुतेक server-side भाषा/सिस्टम्स (Unix shell, Python चे time.time(), PHP चे time(), बहुतेक databases) seconds वापरतात. JavaScript चे Date.now() आणि new Date().getTime() मात्र milliseconds परत करतात. JavaScript frontend आणि backend APIs यांच्यात संवाद होताना हा फरक bugs चे एक सामान्य कारण ठरतो.

seconds मधला Unix timestamp सध्या साधारण 10 अंकी असतो (2023 मध्ये अंदाजे 1,700,000,000). millisecond timestamp 13 अंकी असतो. calculator digits पाहून format ओळखतो आणि तसा conversion करतो.

Year 2038 problem

ज्या सिस्टम्स Unix timestamp signed 32-bit integer म्हणून साठवतात, त्या epoch नंतर जास्तीत जास्त 2,147,483,647 seconds पर्यंतच्या तारखा सादर करू शकतात — म्हणजे 19 जानेवारी 2038 रोजी 03:14:07 UTC पर्यंत. त्या क्षणानंतर 32-bit signed integer overflow होऊन मोठ्या negative नंबरमध्ये बदलतो, आणि तो 1901 मधली तारीख दर्शवतो.

याला कधी कधी “Y2K38” problem किंवा “Unix Millennium Bug” असेही म्हणतात. आधुनिक 64-bit सिस्टम्सवर हा परिणाम होत नाही, कारण signed 64-bit integer सुमारे 292 अब्ज वर्षांपर्यंतच्या timestamps सादर करू शकतो. पण embedded systems, legacy databases आणि जुन्या 32-bit सॉफ्टवेअरमध्ये हा धोका अजूनही असू शकतो. टेलिकॉम, बँकिंग आणि औद्योगिक नियंत्रण प्रणाली (industrial control systems) अशा अनेक उद्योगांमध्ये यासाठी migration सुरू आहे.

सध्याचा Unix timestamp कसा मिळवायचा

Language / environment	Command
JavaScript	Math.floor(Date.now() / 1000)
Python	import time; int(time.time())
PHP	time()
Bash	date +%s
SQL (PostgreSQL)	EXTRACT(EPOCH FROM NOW())::int
SQL (MySQL)	UNIX_TIMESTAMP()
Go	time.Now().Unix()
Rust	SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs()

Practical uses

API development: REST APIs मध्ये created_at, updated_at, आणि token expiry fields साठी Unix timestamps मोठ्या प्रमाणावर वापरले जातात. timestamp timezone-agnostic आणि unambiguous असतो — formatted date strings प्रमाणे locale/format वर अवलंबून नसतो.

Token expiry: JWT (JSON Web Tokens) मध्ये exp (expiry) आणि iat (issued at) claims साठी Unix timestamps वापरतात. current timestamp exp पेक्षा मोठा झाला की token expire होतो. “हा token 24 तासांनी expire व्हावा” असे हिशोब करण्यासाठी current timestamp मध्ये 86,400 seconds जोडावे लागतात.

Cache TTL: cache expiry बहुतेक वेळा Unix timestamp म्हणून किंवा “आत्तापासून किती seconds” म्हणून ठेवतात. cache समस्यांची debugging करताना साठवलेला expiry timestamp human-readable date मध्ये convert करणे हा पहिला step असतो.

Log analysis: server logs मध्ये अनेकदा Unix timestamps असतात. त्यांना वाचण्यायोग्य तारीख-वेळेत रूपांतरित करणे हे log entries आणि वास्तविक घटनांचा संबंध (correlation) लावण्यासाठी पहिलं पाऊल असतं.

Database storage: timestamps formatted strings ऐवजी integers म्हणून साठवल्यास timezone conversion bugs टाळता येतात आणि sorting, range queries, arithmetic सोपी होते. “शेवटच्या 7 दिवसांतील सर्व records” अशी query WHERE created_at > (NOW_UNIX - 604800) अशी करता येते.