مبدل Epoch

خاستگاه زمان یونیکس

برای درک واقعی زمان‌مهر epoch که اغلب زمان یونیکس، زمان POSIX یا صرفاً epoch نامیده می‌شود، باید به خاستگاه سیستم‌عامل یونیکس در اوایل دهه ۱۹۷۰ برگردیم. زمان یونیکس سامانه ردیابی زمان به‌صورت مجموع در حال اجرای ثانیه است. مشخصاً تعداد ثانیه‌های سپری‌شده از epoch یونیکس را نشان می‌دهد. خود epoch به‌صورت ۰۰:۰۰:۰۰ زمان هماهنگ جهانی (UTC) در پنجشنبه ۱ ژانویه ۱۹۷۰ تعریف شده است.

وقتی کن تامپسون و دنیس ریچی نخستین نسخه‌های یونیکس را در آزمایشگاه بل می‌ساختند، راه ساده و کارآمدی برای نمایش و ذخیره تاریخ و زمان لازم داشتند. تاریخ خوانای انسان (مثل «۲۹ ژوئیه ۲۰۲۶») برای رایانه بسیار پیچیده است: ماه نامنظم (۲۸، ۲۹، ۳۰ یا ۳۱ روز)، سال کبیسه، منطقه زمانی و گذار ساعت تابستانی. با نمایش زمان به‌صورت یک عدد صحیح پیوسته افزایشی، توسعه‌دهندگان یونیکس استاندارد زمانی جهانی و بدون ابهام ساختند که به‌راحتی ذخیره، مقایسه و ریاضی دستکاری شود.

چرا توسعه‌دهندگان امروز از زمان‌مهر Epoch استفاده می‌کنند

حتی دهه‌ها بعد، زمان epoch ستون فقرات زیرساخت رایانش مدرن است. دلایل پذیرش جهانی:

1. سادگی و کارایی: ذخیره عدد صحیح ۳۲بیتی یا ۶۴بیتی به‌مراتب کمتر از رشته تاریخ قالب‌شده جا و حافظه می‌گیرد. وقتی پایگاه میلیاردها رکورد دارد، ذخیره چند بایت در هر ردیف هزینه ذخیره را به‌شدت کم و عملکرد نمایه را بهتر می‌کند.
2. مستقل از منطقه زمانی: زمان‌مهر epoch ذاتاً به UTC گره خورده و به مکان فیزیکی کاربر اهمیت نمی‌دهد. وقتی سرور توکیو با کلاینت نیویورک حرف می‌زند، ارسال عدد صحیح epoch سردرگمی منطقه زمانی را حذف می‌کند. کلاینت عدد را هنگام دریافت به منطقه محلی تبدیل می‌کند.
3. عملیات ریاضی آسان: محاسبه مدت بین دو رویداد به‌سادگی تفریق یک زمان‌مهر از دیگری است. برای دانستن ثانیه‌های بین دو ورودی لاگ، timestamp2 - timestamp1 پاسخ دقیق را فوری می‌دهد بدون منطق پیچیده تجزیه تاریخ.
4. مرتب‌سازی پایگاه داده: مرتب‌سازی زمانی رکورد با ستون عدد صحیح برای موتور پایگاه به‌مراتب سریع‌تر از تجزیه و مرتب‌سازی رشته زمان‌مهر متنی است.

تأثیر ثانیه کبیسه

یک نکته فنی زمان یونیکس نحوه برخورد با ثانیه کبیسه است. ثانیه کبیسه تنظیم یک‌ثانیه‌ای است که گاه به زمان هماهنگ جهانی (UTC) اعمال می‌شود تا زمان روز نزدیک زمان خورشیدی میانگین بماند. جالب اینکه زمان یونیکس ثانیه کبیسه را حساب نمی‌کند. در سامانه زمان یونیکس هر روز دقیقاً ۸۶۴۰۰ ثانیه فرض می‌شود. وقتی ثانیه کبیسه رخ می‌دهد، ساعت یونیکس اساساً همان ثانیه را دو بار تکرار می‌کند. این انتخاب عمدی از غیرقابل‌پیش‌بینی شدن زمان‌مهر جلوگیری می‌کند، هرچند یعنی زمان یونیکس معیار خطی سخت زمان فیزیکی سپری‌شده از ۱۹۷۰ نیست. برای اکثر کاربرد مهندسی نرم‌افزار این اختلاف جزئی کاملاً پذیرفتنی و بر پیچیدگی ردیابی هر ثانیه کبیسه تاریخی ترجیح دارد.

تبدیل زمان‌مهر epoch به تاریخ خوانا از رایج‌ترین کارهای توسعه‌دهنده است؛ برای لاگ سرور، رابط یا رکورد پایگاه. چون زمان یونیکس استاندارد جهانی است، تقریباً هر زبان کتابخانه داخلی دارد. پایین، تبدیل زمان‌مهر ۱۰ رقمی (ثانیه) به رشته تاریخ در چند زبان آمده است.

JavaScript / Node.js

در JavaScript شیء بومی Date زمان را مدیریت می‌کند. مهم است به خاطر بسپارید که سازنده Date میلی‌ثانیه می‌خواهد نه ثانیه. برای تبدیل زمان‌مهر استاندارد یونیکس باید آن را در ۱۰۰۰ ضرب کنید.

// The Unix timestamp in seconds
const unixTimestamp = 1672531200;

// Convert to milliseconds by multiplying by 1000
const dateObject = new Date(unixTimestamp * 1000);

// Output in local time zone
console.log(dateObject.toLocaleString()); 
// Example output: '12/31/2022, 7:00:00 PM'

// Output in UTC
console.log(dateObject.toUTCString());
// Example output: 'Sun, 01 Jan 2023 00:00:00 GMT'

Python

ماژول داخلی datetime در Python این کار را بسیار ساده می‌کند. متد fromtimestamp() زمان‌مهر را بر حسب ثانیه می‌گیرد و شیء datetime محلی برمی‌گرداند و utcfromtimestamp() شیء datetime در UTC برمی‌گرداند.

import datetime

unix_timestamp = 1672531200

# Convert to local time
local_time = datetime.datetime.fromtimestamp(unix_timestamp)
print(local_time.strftime('%Y-%m-%d %H:%M:%S'))

# Convert to UTC
utc_time = datetime.datetime.utcfromtimestamp(unix_timestamp)
print(utc_time.strftime('%Y-%m-%d %H:%M:%S'))

PHP

PHP سابقه طولانی در ابزار عالی دستکاری تاریخ و زمان دارد. تابع استاندارد date() اجازه می‌دهد زمان‌مهر یونیکس را مستقیم با دادن آن به‌عنوان آرگومان دوم قالب‌بندی کنید.

$unix_timestamp = 1672531200;

// Convert and format the timestamp
$readable_date = date('Y-m-d H:i:s', $unix_timestamp);

echo $readable_date;

Java

در Java مدرن (Java 8 و جدیدتر) بسته java.time روش توصیه‌شده برای کار با تاریخ است. کلاس Instant یک لحظه مشخص روی خط زمان را نشان می‌دهد.

import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
import java.time.ZonedDateTime;

public class EpochConverter {
    public static void main(String[] args) {
        long unixTimestamp = 1672531200L;
        
        // Create an Instant from seconds
        Instant instant = Instant.ofEpochSecond(unixTimestamp);
        
        // Convert to a specific time zone (e.g., UTC)
        ZonedDateTime dateTime = ZonedDateTime.ofInstant(instant, ZoneId.of("UTC"));
        
        // Format the output
        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
        System.out.println(dateTime.format(formatter));
    }
}

Go (Golang)

بسته time در Go مقاوم و بسیار کارآمد است. می‌توانید از تابع time.Unix() استفاده کنید که ثانیه و نانوثانیه را به‌عنوان آرگومان می‌گیرد.

package main

import (
	"fmt"
	"time"
)

func main() {
	unixTimestamp := int64(1672531200)
	
	// Convert timestamp (seconds, nanoseconds)
	t := time.Unix(unixTimestamp, 0)
	
	// Print in default format
	fmt.Println(t.Format(time.RFC3339))
}

درک این پیاده‌سازی‌های پایه کمک می‌کند منطق زمان را در هر پشته فنی محکم بنویسید.

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

ریسک پنهان بارگذاری روی سرور

فرستادن داده به سرور ناشناس ثالث آسیب‌پذیری امنیتی شدید می‌آورد. حتی زمان‌مهر به‌ظاهر بی‌ضرر یونیکس می‌تواند در بافت بسیار حساس باشد. مثلاً اگر خرابی حیاتی سامانه، نقض امنیت یا الگوریتم معاملاتی اختصاصی را اشکال‌زدایی می‌کنید، زمان‌مهر دقیق آن رویداد محرمانه است. وقتی ابزار مبتنی بر سرور استفاده می‌کنید، رد دیجیتال روی سروری می‌گذارید که کنترلش دست شما نیست. این سرور ممکن است نشانی IP، زمان درخواست و داده دقیق ارسالی را ثبت کند. در بدترین حالت داده شنود شود، در نقض داده نشت کند یا به کارگزار داده ثالث فروخته شود.

برتری Utiliome: اجرای کاملاً خصوصی در مرورگر

دقیقاً به همین دلیل مبدل Epoch ما متفاوت مهندسی شده. قوی باور داریم داده هرگز نباید ماشین را ترک کند. ابزار کاملاً داخل مرورگر با JavaScript سمت کاربر کار می‌کند. وقتی زمان‌مهر را می‌چسبانید و تبدیل می‌کنید، عملیات ریاضی محلی روی CPU رایانه رخ می‌دهد. مطلقاً صفر بارگذاری روی سرور وجود دارد.

این تصمیم معماری چند فایده بزرگ دارد:

1. حریم خصوصی بدون سازش: چون داده هرگز به سرور ما نمی‌رسد، نمی‌توانیم ثبت، ذخیره یا ببینیم. می‌توانید زمان‌مهر مرتبط با حادثه داخلی حساس شرکت، پایگاه محرمانه یا لاگ کاربر خصوصی را با اطمینان تبدیل کنید بدون نقض استاندارد انطباق (مثل GDPR، HIPAA یا SOC2).
2. سرعت برق‌آسا: ابزار سمت سرور از تأخیر شبکه رنج می‌برد. باید منتظر تفکیک DNS، سفر درخواست HTTP به مرکز داده، زمان پردازش و برگشت بمانید. با اجرای کاملاً در مرورگر، بازخورد آنی و زنده می‌دهیم. هنگام تایپ، تبدیل در چند میلی‌ثانیه رخ می‌دهد.
3. قابلیت آفلاین: چون ابزار کاملاً به مرورگر محلی متکی است، پس از بار شدن صفحه حتی با قطع اینترنت بی‌نقص کار می‌کند.

با اولویت دادن به رویکرد در مرورگر و صفر بارگذاری روی سرور، ابزار کاملاً رایگانی می‌دهیم که حریم خصوصی را رعایت می‌کند و گردش‌کار را شتاب می‌دهد.

هرچند زمان یونیکس اختراع درخشانی برای عصر خود بود، بمب ساعتی عظیمی به نام مسئله سال ۲۰۳۸ دارد که اغلب دراماتیک «Epochalypse» نامیده می‌شود. برای درک این بحران فناوری نزدیک، باید ببینیم زمان epoch چگونه در حافظه رایانه ذخیره می‌شود و محدودیت سخت‌افزار و نرم‌افزار قدیمی چیست.

محدودیت عدد صحیح ۳۲بیتی

وقتی یونیکس در دهه ۱۹۷۰ ساخته شد، ذخیره و حافظه بسیار گران و محدود بود. برای صرفه‌جویی فضا، مشخصات اولیه یونیکس زمان epoch را به‌صورت عدد صحیح علامت‌دار ۳۲بیتی ذخیره می‌کرد. در رایانش دودویی، عدد صحیح ۳۲بیتی ۳۲ بیت (یک و صفر) برای نمایش عدد اختصاص می‌دهد. چون «علامت‌دار» است، یک بیت نشان می‌دهد عدد مثبت است یا منفی (تا رایانه تاریخ پیش از ۱ ژانویه ۱۹۷۰ را نشان دهد). این ۳۱ بیت برای اندازه واقعی عدد می‌ماند.

حداکثر مقدار مثبت عدد صحیح علامت‌دار ۳۲بیتی دقیقاً 2,147,483,647 است. بنابراین ساعت یونیکس ۳۲بیتی فقط تا ۲٬۱۴۷٬۴۸۳٬۶۴۷ ثانیه پس از epoch یونیکس می‌شمارد.

در ۱۹ ژانویه ۲۰۳۸ چه رخ می‌دهد؟

اگر ۲٬۱۴۷٬۴۸۳٬۶۴۷ ثانیه به epoch یونیکس (۱ ژانویه ۱۹۷۰ ساعت ۰۰:۰۰:۰۰ UTC) اضافه کنیم، به تاریخ و ساعت بسیار مشخص می‌رسیم: سه‌شنبه ۱۹ ژانویه ۲۰۳۸ ساعت ۰۳:۱۴:۰۷ UTC.

دقیقاً در ۰۳:۱۴:۰۸ UTC عدد صحیح ۳۲بیتی سرریز می‌شود. در رایانش، سرریز عدد صحیح وقتی رخ می‌دهد که عملیات حسابی بخواهد مقداری بزرگ‌تر از فضای ذخیره موجود بسازد. به‌خاطر نحوه پردازش عدد علامت‌دار در حافظه (نمایش دودویی مکمل دو)، عدد به کمترین مقدار منفی «می‌پیچد»: -2,147,483,648.

به‌جای خواندن زمان درست در ۲۰۳۸، رایانه آسیب‌دیده ناگهان زمان را به‌صورت تعداد منفی ثانیه از epoch تفسیر می‌کند و خشن به عقب می‌پرد به جمعه ۱۳ دسامبر ۱۹۰۱.

پیامد دنیای واقعی

پیامد این سرریز عدد صحیح می‌تواند برای سامانه‌هایی که به‌موقع ارتقا نیابند فاجعه‌بار باشد. نرم‌افزاری که تاریخ آینده را حساب می‌کند، سامانه مالی که وام مسکن یا اوراق ۳۰ساله را مدیریت می‌کند، سامانه توکار در زیرساخت و پایگاه قدیمی می‌تواند کاملاً خراب شود یا محاسبه به‌شدت نادرست بدهد. اگر سیستم‌عامل ناگهان باور کند سال ۱۹۰۱ است، گواهی امن SSL/TLS نامعتبر یا هنوز صادرنشده به نظر می‌رسد و ارتباط اینترنت می‌شکند. اسکریپت پشتیبان زمان‌بندی‌شده شکست می‌خورد و تراکنش پایگاه ممکن است به‌خاطر زمان‌مهر غیرممکن خراب شود.

صنعت چگونه آماده می‌شود

خوشبختانه صنعت نرم‌افزار دهه‌ها از مسئله Y2K38 آگاه بوده. راه‌حل در نظریه نسبتاً ساده اما در اجرا جهانی بسیار پیچیده است: مهاجرت سامانه به عدد صحیح ۶۴بیتی برای ذخیره زمان.

عدد صحیح علامت‌دار ۶۴بیتی حداکثر مقدار 9,223,372,036,854,775,807 را ذخیره می‌کند. ترجمه‌شده به زمان یونیکس، ساعت ۶۴بیتی تا ۲۹۲ میلیارد سال دیگر سرریز نمی‌شود—خیلی بعد از اینکه خورشید زمین را ببلعد. سیستم‌عامل مدرن (مثل لینوکس، ویندوز و macOS شصت‌وچهاربیتی)، زمان اجرای زبان مدرن و سامانه فایل به‌روز قبلاً به زمان‌مهر ۶۴بیتی رفته‌اند. اما خطر واقعی در سامانه توکار، دستگاه IoT قدیمی، نرم‌افزار خودرو کهنه و پایگاه کد نگهداری‌نشده است که وصله‌اش سخت یا ناممکن است. با نزدیک شدن ۲۰۳۸، توسعه‌دهندگان باید فعال پایگاه، API و ساختار داده را ممیزی کنند تا کاملاً سازگار ۶۴بیتی باشند.