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 بایت (int 32-بیتی) یا 8 بایت (long 64-بیتی) حجم دارد و از مقایسه مستقیم پشتیبانی می‌کند — بزرگ‌تر timestamp = تاریخ بعدتر.

ریاضیات تبدیل

یک روز = 86 400 ثانیه (24 x 60 x 60). یک ساعت = 3600 ثانیه. برای تبدیل timestamp به تاریخ، باید تعداد روزها، ساعت‌ها، دقیقه‌ها و ثانیه‌ها را از آغاز دوره به ترتیب محاسبه کرد. تبدیل معکوس — تاریخ را به روز از 1970-01-01 تبدیل کرده، سپس ضرب در 86 400 و افزودن انحراف نسبت به UTC. در Java و Kotlin این محاسبات در کلاس‌های استاندارد java.time.Instant و java.util.Date پیاده‌سازی شده‌اند که توسعه‌دهنده را از محاسبات دستی بی‌نیاز می‌کند.

        // دریافت Unix Timestamp به ثانیه
val seconds = System.currentTimeMillis() / 1000

// تبدیل timestamp به تاریخ از طریق java.time
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 مستقل بودن از مکان است. سرور همیشه timestamp را به UTC برمی‌گرداند، و تبدیل به تاریخ و زمان محلی در طرف کلینت انجام می‌شود. در Kotlin برای این کار از ZonedDateTime با ZoneId مناسب استفاده می‌شود — سیستمی یا انتخاب‌شده توسط کاربر. اگر برنامه زمان را در مناطق مختلف نشان می‌دهد (مثلاً برای مسافران)، 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، منطقه = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

مشکل سال 2038

مشکل سال 2038 (Year 2038 Problem، Y2K38) — محدودیت بنیادین عدد صحیح 32-بیتی علامت‌دار برای ذخیره Unix Timestamp است. حداکثر مقدار signed int 32-بیتی 2 147 483 647 است که مربوط به 19 ژانویه 2038 ساعت 03:14:07 UTC است. پس از این تاریخ، مقدار سرریز شده و به یک عدد منفی تبدیل می‌شود که باعث ایجاد مشکل در سیستم‌هایی می‌شود که از time_t 32-بیتی استفاده می‌کنند. این مشکل مانند Y2K مشهور است، اما ابتدا به سیستم‌های داخلی، نسخه‌های کهنه Android و دستگاه‌های IoT با معماری 32-بیتی اثر می‌گذارد.

ابعاد مشکل

بر اساس Linux Foundation (2025)، حدود 15% از دستگاه‌های لینوکس در بخش صنعتی و IoT هنوز از ساخت 32-بیتی استفاده می‌کنند. برای دستگاه‌های Android ریسک پایین‌تر است — اکثر گوشی‌های هوشمند مدرن بر پردازنده‌های 64-بیتی (ARM64) کار می‌کنند، اما مدل‌های قدیمی‌تر با Android 4.x و پایین‌تر ممکن است از time_t 32-بیتی استفاده کنند. راه‌حل مشکل — مهاجرت به time_t 64-بیتی است که تا 292 میلیارد سال ایمن است. از Android 5.0 (API 21) به بعد، همه دستگاه‌ها از زمان 64-بیتی در سطح هسته استفاده می‌کنند. توسعه‌دهندگان اپلیکیشن‌های موبایل فقط به ذخیره timestamp در نوع Long (64-بیتی) نیاز دارند تا از مشکل در سطح برنامه جلوگیری کنند.

کار با Unix Timestamp در Android

در توسعه Android، کار صحیح با Unix Timestamp برای همگام‌سازی داده‌ها، نمایش زمان دریافت پیام‌ها، محاسبه مهلت‌های زمانی و برنامه‌ریزی اعلان‌ها حیاتی است. فراخوانی سیستمی System.currentTimeMillis() زمان فعلی را به میلی‌ثانیه از دوره Unix برمی‌گرداند — این دقیق‌ترین منبع زمان موجود در دستگاه است. برای درخواست‌های شبکه معمولاً از Unix Timestamp به ثانیه استفاده می‌شود، زیرا اکثر REST API‌ها و پایگاه‌های داده دقیقاً با ثانیه کار می‌کنند.

روش‌های توصیه‌شده

هرگز از System.currentTimeMillis() برای اندازه‌گیری فاصله‌های زمانی استفاده نکنید — برای این کار System.nanoTime() وجود دارد که یکنواخت است و به تغییرات ساعت توسط کاربر بستگی ندارد. برای نمایش زمان، همیشه timestamp را به UTC ذخیره کنید و در طرف واسط کاربر به منطقه زمانی محلی تبدیل کنید. در کار با پایگاه‌های داده (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 ذخیره کرده و از فهرست بر روی ستون زمان استفاده کنید.

توصیه‌ها برای پروژه‌های موبایل

برای برنامه‌های Android با کتابخانه Room، توصیه می‌شود timestamp را به عنوان Long (64-بیتی) ذخیره کرده و از TypeConverter برای تبدیل خودکار بین Long و Date یا Instant استفاده کنید. در پرس‌وجوهای پایگاه داده از اپراتورهای مقایسه (>، <، BETWEEN) استفاده کنید — آنها با انواع عددی به صورت داخلی کار می‌کنند. برای ذخیره موقت داده‌هایی که نیاز به مرتب‌سازی بر اساس زمان دارند (مثلاً لیست پیام‌ها)، حتماً یک فهرست بر روی ستون timestamp ایجاد کنید — این پرس‌وجوهای ORDER BY را در حجم بالای داده چندین مرتبه تسریع می‌بخشد.