Unix Timestamp: یہ کیا ہے، تبدیلی اور موبائل ڈویلپمنٹ میں ذخیرہ

Unix Timestamp کیا ہے؟

Unix Timestamp (POSIX time، Epoch time یا Unix time کے نام سے بھی جانا جاتا ہے) وقت کی پیمائش کا ایک نظام ہے جو یکم جنوری 1970 00:00:00 UTC (Unix عہد) سے گزرے ہوئے سیکنڈز کی تعداد کو متعین کرتا ہے۔ یہ تاریخ Unix آپریٹنگ سسٹم کے لیے نقطہ آغاز کے طور پر منتخب کی گئی تھی، اور بعد میں یہ فارمیٹ کمپیوٹنگ سسٹمز میں وقت کی نمائندگی کے لیے حقیقی معیار بن گیا۔ Timestamp لیپ سیکنڈز کو مدنظر نہیں رکھتا — ہر منٹ کو 60 سیکنڈ شمار کیا جاتا ہے، حالانکہ بین الاقوامی زمینی گردش سروس بعض اوقات ایٹمی وقت کو درست کرنے کے لیے ایک اضافی سیکنڈ شامل کرتی ہے۔

Unix عہد: 1970 کیوں؟

یکم جنوری 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 ایپلی کیشنز کے لیے، timestamp کو Long (64 بٹ) کے طور پر ذخیرہ کرنے اور Long اور Date یا Instant کے درمیان خودکار تبدیلی کے لیے TypeConverter استعمال کرنے کی سفارش کی جاتی ہے۔ ڈیٹا بیس میں استفسار کرتے وقت، موازنہ آپریٹرز (>، <، BETWEEN) استعمال کریں — یہ عددی اقسام کے ساتھ نیٹو طور پر کام کرتے ہیں۔ وقت پر مبنی ترتیب کی ضرورت والے ڈیٹا (مثلاً پیغامات کی فہرست) کو کیش کرنے کے لیے، ہمیشہ timestamp کالم پر انڈیکس بنائیں — یہ بڑے ڈیٹا والیوم کے ساتھ ORDER BY والے استفسارات کو کئی گنا تیز کرے گا۔