Windows FILETIME Dönüştürücü

Dönüştürmek için bir FILETIME tik değeri veya tarih girin.

Nasıl hesaplanır?

Windows FILETIME, 1601-01-01 00:00:00 UTC'den itibaren geçen 100 nanosaniyelik tikleri sayar. Araç, tik değerini okumak için unix saniye = tik ÷ 10.000.000 − 11.644.473.600 formülünü kullanır; sabit sayı, 1601 ile 1970 arasındaki saniye farkıdır ve sonuç UTC olarak biçimlendirilir. Ters yönde tik = (unix saniye + 11.644.473.600) × 10.000.000 olur; yazdığınız metin, +02:00 gibi kendi farkını taşımıyorsa UTC tarih ve saat olarak okunur. Tikten tarihe dönüşüm en yakın saniyeye yuvarlanır, yani son yedi hanelik hassasiyet kaybolur; negatif tik değerleri sonuç vermez. Sunucunun okuyabildiği her tarih metni kabul edilir, okunamayan metin sonuç vermez.

Örnek hesaplama

Bir Active Directory özniteliği 133500000000000000 tik değerini gösteriyor. 10.000.000'a bölünce 1601'den beri 13.350.000.000 saniye elde edilir. 1601 ile 1970 arasındaki 11.644.473.600 saniyelik farkı çıkarın: 13.350.000.000 − 11.644.473.600 = 1.705.526.400 saniye (1970'ten beri Unix zamanı). Bu değer 2024-01-17 21:20:00 UTC tarihine denk gelir. Aynı tarihle ters yöne gidilirse tam olarak 133.500.000.000.000.000 tik bulunur.

Bu örneği dene →

Sık yapılan hatalar

  • Sayıyı Unix saniyesi ya da milisaniyesi sanmak. FILETIME yaklaşık 18 haneli bir sayıdır; 10 haneli değer Unix zamanı, 13 haneli değer Unix milisaniyesidir ve ikisi de bu alana uygun değildir.
  • Çıktıyı yerel saat sanmak. Sonuç her zaman UTC'dir; yerel saatle karşılaştırmadan önce saat diliminize kendiniz çevirin.
  • Saat dilimi olmadan tarih yazıp yerel saat beklemek. Farkı olmayan metin UTC olarak okunur; tarih yerel ise +02:00 gibi bir fark ekleyin, araç doğru kaydırır.
  • Bir araçta görülen yüksek ve alçak parçalar gibi onaltılık bir değer yapıştırmak. Tik değeri ondalık bir sayı olmalıdır; onaltılık değer ya da boşluk veya virgül içeren değer okunmaz.
  • Saniyenin altında ayrıntı beklemek. Tarih sonucu saniyeye yuvarlanır; birkaç milyon tik farkı olan değerler aynı saati gösterebilir.

Bu hesaplama hakkında

Windows, zaman damgalarını dahili olarak FILETIME değerleri olarak temsil eder — 1 Ocak 1601, 00:00:00 UTC'den itibaren geçen 100 nanosaniyelik aralıkların ("tik") 64 bitlik sayımı; bu referans tarih, epoch'tan önceki ilk tam 400 yıllık Gregoryen takvim döngüsünü başlattığı için seçilmiştir. Bu format Windows ekosisteminde her yerde karşımıza çıkar: NTFS dosya oluşturma/değiştirme zaman damgaları, Windows Olay Günlüğü kayıtları ve Active Directory'deki lastLogonTimestamp ile pwdLastSet gibi öznitelikler hep bu şekilde saklanır.

İnsan tarafından okunabilir bir tarihe (veya daha tanıdık olan 1 Ocak 1970 Unix epoch'una) dönüştürmek, iki epoch arasındaki farkın — 11.644.473.600 saniye veya 100 nanosaniyelik tik cinsinden 116.444.736.000.000.000 — çıkarılmasını, ardından Unix saniyesini elde etmek için 10.000.000'a bölünmesini gerektirir. Dijital adli bilişim araştırmacıları ve olay müdahale uzmanları, kendiliğinden biçimlendirilmiş bir tarih göstermeyen ham Windows kanıtlarını okurken FILETIME değerlerini sürekli çözer.

Bu faydalı oldu mu?

En fazla 3 tepki seçebilirsiniz.

Yorumlar (1)

  • Editör ekibi

    Active Directory'de iki değer burada tuhaf görünür. accountExpires için 0 ya da 9223372036854775807 hesabın hiç sona ermediği anlamına gelir; araç yine de somut bir tarih yazar: ilki için 1601, ikincisi için 30828 yılı. Bunları tarih değil işaret olarak okuyun. En çok hangi öznitelikleri çözüyorsunuz: lastLogon, pwdLastSet ya da başka biri?

Popüler hesaplayıcılar

Tüm Hesaplayıcılar