Unix zaman damgası dönüştürücü

Unix zaman damgası nedir

Bir Unix zaman damgası — epoch zamanı ya da POSIX zamanı da denir — 1 Ocak 1970, 00:00:00 UTC’den, yani Unix epoch olarak bilinen andan bu yana kaç saniye geçtiğini sayan tek bir sayıdır. Saat dilimi, takvim ve biçimlendirme olmayan tek bir tam sayı olduğu için, bir zaman anının saklanması, sıralanması, karşılaştırılması ya da bir ağ üzerinden gönderilmesi gerektiğinde bilgisayarların başvurduğu biçimdir. Veritabanınızdaki «created_at» sütununun, bir JWT’deki «iat» ve «exp» taleplerinin, bir dosyanın mtime değerinin ve okuyacağınız neredeyse her günlük dosyasındaki zaman damgalarının ardında duran şey budur.

Ödünleşim şu: çıplak bir sayı bir insan için hiçbir anlam ifade etmez. 1716197600 kusursuz bir andır, ama onun geçen Salı mı yoksa üç yıl önce mi olduğunu bir bakışta anlayamazsınız. Bu çeviriyi, her iki yönde de, bu araç yapar.

Saniye mi milisaniye mi — canını yakan belirsizlik

Özgün Unix kuralı tam saniyeleri sayar; bir kabukta date +%s’ten, PHP’nin time() işlevinden ve kırpıldığında Python’un time.time() değerinden aldığınız budur. JavaScript, Java ve daha birçoğu ise milisaniye sayar: Date.now() bin kat daha büyük bir sayı döndürür. İkisine de «zaman damgası» denir ve onları karıştırmak var olan en yaygın tarih hatalarından biridir.

Bu hata gürültülü değil, sessizdir. Bir milisaniye değerini saniye olarak okuyun, tarihiniz gelecekte on binlerce yıl ileri düşer; bir saniye değerini milisaniye olarak okuyun, her şey Ocak 1970’e çöker. Hiçbiri hata vermez — yalnızca, gerçek görünen yanlış bir tarih alırsınız.

Bu araç, sayının büyüklüğünden tahmin eder ve sonra ne tahmin ettiğini sonucun hemen yanında size söyler. Bugünün epoch saniyeleri on basamaklı, bugünün epoch milisaniyeleri on üç basamaklıdır; bu yüzden tahmin neredeyse her zaman doğrudur — ama bir hata raporuna yapıştırmak üzere olduğunuz bir değer için «neredeyse» yeterince iyi değildir; okumanın her zaman görünür ve değiştirmekten bir tık uzakta olmasının nedeni budur.

Saat dilimleri, UTC ve «yerel»in neden kaygan olduğu

Bir Unix zaman damgasının saat dilimi yoktur. Bir anı tanımlar: 1716197600, 2024-05-20T09:33:20Z demektir; aynı o an, aynı anda Londra’da 10:33, Kudüs’te 12:33 ve Tokyo’da 18:33’tür, çünkü o gün Londra ve Kudüs yaz saatindedir, Japonya’da ise yaz saati hiç yoktur. Bir saat dilimi değerin parçası değildir; değere baktığınız bir mercektir.

Bu araç aynı anda birkaç merceği bu yüzden gösterir. UTC, her sunucunun ve günlüğün üzerinde anlaştığı nötr referanstır. Yerel saatiniz, kendi cihazınızın bildirdiği şeydir; hangi merceğin onu ürettiğini her zaman bilesiniz diye saat dilimi adıyla (Europe/Berlin gibi) gösterilir — algılama tarayıcınızda gerçekleşir; böylece Berlin’deki bir ziyaretçi Berlin saatini, Tokyo’daki bir ziyaretçi Tokyo saatini görür. Üçüncü satır, tam IANA saat dilimi veritabanından seçtiğiniz herhangi bir saat dilimidir; başka bir yerde yaşayan bir sunucudan bir günlük okurken istediğiniz satır budur.

• UTC — her sistemin üzerinde anlaştığı referans ve saklanacak ve günlüğe yazılacak doğru şey.
• Yerel — cihazınızın gördüğü aynı an; algılanan saat dilimiyle etiketlenmiş.
• Seçtiğiniz bir saat dilimi — başka yerlerdeki makinelerden günlük ve izleri okumak için.
• ISO 8601 — değişim metin biçimi, örn. 2024-05-20T09:33:20.000Z.
• Göreli — «3 saat önce», bir şeyin ne kadar yakın zamanda olduğunu hızlıca anlamak için.

Kaymalar her zamanın yanında gösterilir (+03:00, -04:00), çünkü sabit değildir: çoğu saat dilimi yaz saati için bir saat kayar, dolayısıyla aynı saat dilimi yılın farklı zamanlarında farklı kaymalar üretebilir. Bir geçişe yakın bir tarih, tam da elle yapılan aritmetiğin yanıldığı yerdir.

Pratikte epoch zamanıyla çalışma

Her dilin ve kabuğun epoch değerlerini üretmenin ve okumanın kendi yolu vardır. Aklınızda tutmaya değer olanlar şunlardır:

date +%s                         # shell: current time in seconds
date -d @1716197600              # shell (GNU): seconds back to a date
Date.now()                       # JavaScript: current time in MILLIseconds
new Date(1716197600 * 1000)      # JavaScript: seconds to a Date
time.time()                      # Python: seconds, as a float
datetime.fromtimestamp(1716197600, tz=timezone.utc)
SELECT EXTRACT(EPOCH FROM now()) -- PostgreSQL: seconds

Çoğu tarih derdinden kaçınan bir başparmak kuralı: anları UTC olarak saklayın ve iletin — ya bir epoch tam sayısı ya da bir ISO 8601 dizesi — ve yalnızca son anda, birine gerçekten gösterdiğinizde bir yerel saat dilimine çevirin. Erken biçimlendirmek, bir saat dilimi hatasının görünüm katmanınızda kalmak yerine verinize gömülmesinin yoludur.

Bilmeye değer bir şey daha: işaretli 32 bitlik bir saniye sayacı 19 Ocak 2038’de dolar, «2038 Yılı sorunu». Modern sistemler 64 bitlik değerler kullanır ve sorunsuzdur, ama eski gömülü cihazlar ve eski veritabanı sütunları, onunla hâlâ karşılaşabileceğiniz yerlerdir.

Epoch nedir ve neden her zaman damgası 1970’ten başlamaz

Bu anlamda bir epoch, yalnızca seçilmiş bir sıfırdır — bir sayacın saymaya başladığı, tanımlanmış an. Unix epoch, 1 Ocak 1970, 00:00:00 UTC’dir ve bir şeyden türetildiği için değil, elverişli ve yuvarlak bir tarih olduğu için seçilmiştir: biçimin kendisi özellikle o günü gerektirmez. Erken Unix, çok daha yakın bir sıfırdan saniyenin altmışta birlerini sayıyordu ve üçüncü baskı elkitabı bunun neden süremeyeceğini açıkça söyledi: altmışta birlerin otuz iki biti her 2,26 yılda bir kriz garanti eder, yani yaklaşık her 828 günde bir. Aynı otuz iki bitteki tam saniyeler yüz otuz altı yıla, sayaç işaretliyse altmış sekiz yıla ulaşır; bu da yukarıdaki 2038 tarihidir.

Bu geçmiş, uzun bir sayıya güvenmeden önce onu denetlemenin nedenidir. Başka sistemler başka sıfırlardan ve başka çözünürlüklerle sayar; birini Unix saniyesi olarak okumak sizi birkaç saat değil, yüzyıllar şaşırtır. Karşınıza en çok çıkacak olanlar şunlardır:

• Windows FILETIME — 1 Ocak 1601 UTC’den bu yana yüz nanosaniyelik tikler. Unix saniyesi için on milyona bölün ve 11644473600 çıkarın; bu kılavuz boyunca kullanılan 1716197600 anı, o düzende 133606712000000000’dir.
• .NET DateTime.Ticks — aynı yüz nanosaniyelik tik, ama 1 yılının başından sayılır. Unix epoch’un kendisi 621355968000000000 tikte durur; bölmeden önce çıkarılacak sayı budur.
• Apple’ın referans tarihi — 1 Ocak 2001 UTC’den bu yana saniyeler; Cocoa ve Core Data bunu kullanır. Unix saniyesi için 978307200 ekleyin: 1716197600, orada 737890400’dür.
• Excel’in seri numaraları — saniye değil gün ve 30 Aralık 1899’dan sayılır, çünkü Excel 1900’ü artık yıl sayar, oysa değildi.
• GPS zamanı — 6 Ocak 1980’den bu yana saniyeler; hiçbir artık saniyeyi atlamadan sayılır, bu yüzden GPS zamanı ile UTC artık uyuşmaz.

Sonuncusu, Unix değerinin kendisi için de doğru olan bir şeye işaret eder: o bir kronometre okuması değildir. POSIX onu, epoch’tan bu yana geçen saniyelere yaklaşan bir değer olarak tanımlar ve her bir günün tam olarak 86400 saniyeyle sayılmasını şart koşar — yani UTC’ye eklenen artık saniyeler hiç sayılmaz. Bu yüzden iki Unix zaman damgası arasındaki fark, gerçekten geçen saniyelerin sayısı değil, aralarındaki takvim saniyelerinin sayısıdır; ve değer en iyi, UTC takvim okumasının bir kodlaması olarak anlaşılır. Hiçbir zaman damgasının bir artık saniyeyi adlandıramamasının nedeni de budur: bu kodlamada artık saniyeye yer yoktur.

Bir tarihten epoch değerine: kabuk, JavaScript ve Python

Yukarıdaki blok bir epoch değerini okunabilir bir şeye çevirir. Ters yön — elinizde zaten olan bir tarihin, metin ya da sayı kümesi olarak, bir epoch değerine dönüşmesi — saat dilimi hatalarının yaşadığı yerdir; çünkü metin bir saat dilimi adı vermediğinde bunların her biri sessizce bir saat dilimi varsayar. İşte aynı iş üç yolla, bu kılavuzun 2024-05-20T09:33:20Z anı üzerinde. Kabuk satırları GNU date’idir; BSD ve macOS’un date’i başka seçenekler alır.

date -u -d '2024-05-20 09:33:20' +%s     # 1716197600 — -u reads the text as UTC
date -d '2024-05-20 09:33:20 UTC' +%s    # the same, with the zone named in the text
date -d '2024-05-20 09:33:20' +%s        # neither: your machine's zone, another instant

Date.parse('2024-05-20T09:33:20Z') / 1000    // 1716197600 — the Z is what makes it UTC
new Date('2024-05-20T09:33:20Z').getTime()   // the same instant in milliseconds
Date.parse('2024-05-20 09:33:20')            // no Z: your machine's zone, another instant

from datetime import datetime, timezone
int(datetime(2024, 5, 20, 9, 33, 20, tzinfo=timezone.utc).timestamp())   # 1716197600 — an aware datetime
int(datetime.fromisoformat('2024-05-20T09:33:20+00:00').timestamp())     # the same, parsed from a string
int(datetime(2024, 5, 20, 9, 33, 20).timestamp())                        # naive: your machine's zone

Örüntü üçünde de aynıdır: saat dilimini adlandırın, yoksa makinenin ayarlı olduğu saat dilimini miras alırsınız. Kendi dizüstünüzde doğru, bir meslektaşınızınkinde saatlerce yanlış olan bir sayı neredeyse her zaman budur; yukarıdaki aracın sizin yerinize birini seçmek yerine UTC ile yerel okumanızı yan yana göstermesinin nedeni de budur. Sayı zaten elinizdeyse ve gözle denetlemek istiyorsanız, bu sayfanın en üstündeki alana yapıştırın.