تبدیل Unix Timestamp به تاریخ شمسی و میلادی

رایج‌ترین موقعیت، خواندن لاگ است. وقتی خطایی در لاگ اپلیکیشن با زمان 1760000000 ثبت شده، باید بدانید آن لحظه به وقت تهران ساعت چند بوده تا با گزارش کاربر یا رخداد دیگری تطبیق دهید. موقعیت دوم، کار با API است: بسیاری از سرویس‌ها زمان ایجاد، انقضا یا آخرین تغییر را به‌صورت عددی برمی‌گردانند.

در توکن‌های JWT هم فیلدهای exp‏، iat و nbf همگی Unix Timestamp به ثانیه‌اند. اگر توکنی زودتر از انتظار منقضی می‌شود، کافی است payload آن را در دیکدر JWT باز کنید و مقدار exp را اینجا تبدیل کنید. در پایگاه داده هم وقتی ستون زمان به شکل عدد ذخیره شده، برای نوشتن کوئری بازهٔ زمانی باید مرز بازه را به timestamp تبدیل کنید.

در کادر اصلی یک عدد وارد می‌کنید و تبدیل همان لحظه انجام می‌شود. بالای نتیجه تاریخ شمسی با نام روز هفته و ساعت به وقت تهران، تاریخ میلادی و فاصلهٔ آن لحظه از اکنون (مثلاً «۳ روز پیش» یا «۲ ساعت دیگر») آمده است. زیر آن هشت قالب آمادهٔ کپی هست: تاریخ شمسی عددی، تاریخ میلادی به وقت تهران همراه اختلاف ساعت، همان لحظه به UTC، قالب ISO 8601 به UTC و با اختلاف تهران، قالب HTTP-date که در هدرهایی مثل Expires و Last-Modified به کار می‌رود، و مقدار به ثانیه و میلی‌ثانیه. کنار هر سطر دکمهٔ کپی قرار دارد. به‌جای عدد می‌توانید تاریخ ISO 8601 دارای منطقهٔ زمانی، مثل خروجی لاگ‌ها و APIها، را هم بچسبانید.

نوار بالای ابزار زمان حال را به تاریخ شمسی و به‌صورت timestamp نشان می‌دهد و هر ثانیه به‌روز می‌شود؛ دکمهٔ «تبدیل لحظهٔ اکنون» همان را در مبدل می‌گذارد. در کارت دوم، «تاریخ به Timestamp»، تاریخ را به تقویم شمسی یا میلادی و ساعت را به وقت تهران یا UTC وارد می‌کنید و timestamp متناظر را به ثانیه، میلی‌ثانیه و ISO 8601 می‌گیرید. نمونه‌های زیر کادر هم با یک کلیک بارگذاری می‌شوند: صفر (آغاز Epoch)، آغاز سال ۲۰۲۵ به ثانیه و میلی‌ثانیه، بزرگ‌ترین مقدار عدد صحیح ۳۲ بیتی علامت‌دار و یک لحظه در تابستان ۱۳۸۷ که ساعت تابستانی داشت.

همهٔ خروجی‌ها با تایپ هر رقم دوباره محاسبه می‌شوند، پس می‌توانید عدد را تکه‌تکه تغییر دهید و اثرش را ببینید؛ مثلاً با افزودن ۸۶۴۰۰ به یک timestamp دقیقاً یک روز جلو می‌روید و با افزودن ۳۶۰۰ یک ساعت. اگر ورودی عدد معتبری نباشد، مثلاً حروف داشته باشد یا تاریخ بدون منطقهٔ زمانی باشد، دلیل دقیق خطا زیر کادر نمایش داده می‌شود و خروجی‌ها پنهان می‌شوند تا نتیجهٔ قبلی را با نتیجهٔ جدید اشتباه نگیرید. عدد واردشده در بخش # آدرس صفحه هم می‌نشیند، پس می‌توانید لینک همان تبدیل را برای همکارتان بفرستید؛ این بخش آدرس به سرور ارسال نمی‌شود.

همهٔ سیستم‌ها timestamp را با یک واحد ذخیره نمی‌کنند. PHP و بیشتر ابزارهای لینوکسی ثانیه برمی‌گردانند، ولی JavaScript و Java به‌طور پیش‌فرض میلی‌ثانیه می‌دهند. timestamp به ثانیه امروز ده رقمی و به میلی‌ثانیه سیزده رقمی است. اشتباه گرفتن این دو باعث می‌شود تاریخ هزاران سال جلو برود یا به ژانویهٔ ۱۹۷۰ برگردد.

حالت «خودکار» ابزار واحد را از تعداد رقم‌های بخش صحیح عدد حدس می‌زند: تا ۱۱ رقم ثانیه، ۱۲ تا ۱۴ رقم میلی‌ثانیه، ۱۵ تا ۱۷ رقم میکروثانیه و ۱۸ رقم و بیشتر نانوثانیه. واحد تشخیص‌داده‌شده زیر کادر نوشته می‌شود. این قاعده برای زمان‌های امروزی درست کار می‌کند، ولی میلی‌ثانیه‌های مربوط به پیش از سال ۱۹۷۳ کمتر از ۱۲ رقم دارند و اشتباهاً ثانیه خوانده می‌شوند. اگر چنین عددی دارید، واحد را دستی روی «میلی‌ثانیه» بگذارید.

timestamp همیشه به UTC اشاره دارد و منطقهٔ زمانی فقط هنگام نمایش وارد بازی می‌شود. وقت رسمی ایران ⁦UTC+03:30⁩ است و از سال ۲۰۲۳ ساعت تابستانی در ایران اجرا نمی‌شود. ابزار برای نمایش وقت تهران از پایگاه دادهٔ مناطق زمانی مرورگر (منطقهٔ Asia/Tehran) استفاده می‌کند؛ پس برای تاریخ‌های قدیمی که ساعت تابستانی داشتند هم ساعت درست نشان داده می‌شود، اختلاف آن روز (مثلاً ⁦+04:30⁩) کنار تاریخ میلادی می‌آید و برچسب «ساعت تابستانی» نمایش داده می‌شود.

تاریخ شمسی با تقویم هجری شمسی خود مرورگر محاسبه می‌شود. همان timestamp را با نام روز هفته، نام ماه شمسی و ارقام فارسی می‌بینید و یک سطر هم به شکل عددی مثل 1404/07/24 برای کپی در صفحه‌گسترده یا گزارش آمده است؛ برای گزارش‌هایی که مخاطب ایرانی دارند نیازی به تبدیل جداگانهٔ میلادی به شمسی نیست.

سیستم‌هایی که timestamp را در یک عدد صحیح ۳۲ بیتی علامت‌دار نگه می‌دارند، فقط تا مقدار 2147483647 جا دارند که برابر با ساعت ۰۳:۱۴:۰۷ روز نوزدهم ژانویهٔ ۲۰۳۸ به وقت UTC است. یک ثانیه بعد، عدد سرریز می‌کند و منفی می‌شود؛ یعنی تاریخ به سال ۱۹۰۱ برمی‌گردد. این همان «مسئلهٔ سال ۲۰۳۸» است و نمونهٔ مرجع سوم ابزار دقیقاً همین مرز را نشان می‌دهد.

سیستم‌عامل‌ها و زبان‌های امروزی تقریباً همه از عدد ۶۴ بیتی استفاده می‌کنند، ولی ستون‌های قدیمی پایگاه داده، سیستم‌های نهفته و فرمت‌های فایل قدیمی هنوز ممکن است ۳۲ بیتی باشند. برای نمونه، نوع TIMESTAMP در MySQL به همین بازه محدود است و برای تاریخ‌های دورتر باید از DATETIME استفاده کرد. خود ابزار اعداد منفی را هم می‌پذیرد، پس تاریخ‌های پیش از ۱۹۷۰ را هم می‌توانید تبدیل کنید؛ مثلاً -86400 یعنی یک روز پیش از آغاز Epoch.

یکی از تصمیم‌های رایج طراحی این است که زمان را به‌صورت عدد timestamp ذخیره کنیم یا با نوع تاریخ خود پایگاه داده. عدد صحیح ساده و قابل‌حمل است و بین زبان‌ها بدون ابهام جابه‌جا می‌شود، ولی خواندن مستقیم آن در کوئری سخت است. نوع‌های تاریخ مثل timestamptz در PostgreSQL یا DATETIME در MySQL خواناترند و توابع تاریخ پایگاه داده روی آن‌ها کار می‌کنند.

قاعدهٔ عملی این است: در هر دو حالت زمان را به UTC ذخیره کنید و فقط هنگام نمایش به وقت تهران تبدیل کنید. اگر از PostgreSQL مدیریت‌شده استفاده می‌کنید، timestamptz انتخاب امنی است و اگر MySQL مدیریت‌شده دارید، مراقب محدودیت ۲۰۳۸ در نوع TIMESTAMP باشید. برای کلید اصلی‌ای که خودش ترتیب زمانی دارد، UUID نسخهٔ ۷ هم گزینهٔ جالبی است، چون ۴۸ بیت اول آن timestamp به میلی‌ثانیه است.

این ابزار کاملاً در مرورگر شما اجرا می‌شود. سرور ایران‌کلاد فقط صفحه را تحویل می‌دهد و تبدیل‌ها با توابع تاریخ و قالب‌بندی بومی مرورگر انجام می‌شوند؛ کد ابزار هیچ درخواستی برای ارسال عدد یا تاریخ واردشده به سرور نمی‌فرستد. «زمان حال» هم از ساعت دستگاه خودتان خوانده می‌شود، نه از سرور.

همین نکته یک پیامد عملی دارد: اگر ساعت دستگاه شما تنظیم نباشد، «زمان حال» و ستون «فاصله از حال» هم به همان اندازه خطا دارند. خود تبدیل timestamp به تاریخ به ساعت دستگاه وابسته نیست و همیشه دقیق است. روی سرورها هم همین اصل برقرار است: سروری که ساعتش با NTP همگام نشده، timestamp‌های نادرست در لاگ ثبت می‌کند و تطبیق رخدادها بین چند سرور را سخت می‌کند. روی سرور لینوکسی با دستور timedatectl می‌توانید ببینید همگام‌سازی ساعت فعال است یا نه و منطقهٔ زمانی سرور چیست؛ این یکی از اولین بررسی‌ها پس از راه‌اندازی هر سرور تازه است.

برای دیباگ سریع لاگ، timestamp مشکوک را اینجا بچسبانید و به وقت تهران ببینید، بعد با لاگ‌های دیگر مقایسه کنید. اگر زمان‌بندی اجرای اسکریپتی را تنظیم می‌کنید، عبارت زمان‌بندی را در ترجمهٔ Cron بررسی کنید و به خاطر داشته باشید cron با ساعت محلی خود سرور کار می‌کند، نه UTC، مگر اینکه منطقهٔ زمانی سرور UTC باشد.

برای پیدا کردن همهٔ timestamp‌ها در یک متن طولانی، الگوی ساده‌ای مثل یک عدد ده‌رقمی را در تست Regex امتحان کنید و برای مرتب کردن پاسخ API که زمان‌ها را در خود دارد، از فرمت‌کنندهٔ JSON کمک بگیرید. اگر اپلیکیشن خود را روی سرور ابری اجرا می‌کنید، منطقهٔ زمانی سرور را آگاهانه انتخاب کنید و در مستندات تیم ثبت کنید. فهرست همهٔ ابزارها در صفحهٔ ابزارها است.