Bagaimana bisa sebuah file yang telah di 'buat' pada tahun 1641?

Mengapa adalah tanggal dari tahun 1600-an mungkin?

Windows tidak menyimpan file modifikasi cap seperti sistem Unix. Menurut [Windows Dev Center][2] (penekanan dari saya):

file waktu adalah 64-bit nilai yang mewakili jumlah 100 nanodetik interval waktu yang telah berlalu sejak 12:00 A. M. 1 januari 1601 Waktu Universal Terkoordinasi (UTC). Sistem file catatan kali ketika aplikasi membuat, mengakses, dan menulis ke file.

Jadi, dengan menetapkan nilai yang salah di sini, anda dapat dengan mudah mendapatkan tanggal dari tahun 1600-an.

Tentu saja, pertanyaan lain yang penting adalah: bagaimana mengatur nilai ini? Apa adalah tanggal yang sebenarnya? Saya pikir anda'll pernah bisa mengetahui, karena itu bisa saja menjadi sebuah kesalahan perhitungan dalam sistem file driver. Jawaban lain hipotesis bahwa tanggal sebenarnya adalah sebuah Unix timestamp diartikan sebagai Windows timestamp, tapi mereka're-benar dihitung pada interval yang berbeda (detik vs. nanodetik).

Bagaimana hal ini berhubungan dengan Tahun 2038 masalah?

Menggunakan 64-bit tipe data berarti bahwa Windows (umumnya) tidak terpengaruh oleh Tahun 2038 Masalah yang tradisional sistem Unix memiliki, sejak Unix awalnya digunakan 32-bit integer, yang meluap lebih cepat dari versi 64-bit integer yang memiliki sistem operasi Windows. (Ini adalah meskipun operasi Unix pada detik dan operasi Windows pada micro/nano.)

Windows masih dipengaruhi ketika menggunakan program 32-bit yang disusun dengan versi lama dari Visual Studio, tentu saja.

Baru sistem operasi Unix telah diperluas tipe data 64 bit, sehingga menghindari masalah. (Pada kenyataannya, sejak Unix timestamps beroperasi dalam hitungan detik, baru sampul upload akan 292 miliar tahun dari sekarang.)

Apa tanggal maksimal yang dapat diatur?

Untuk yang penasaran – berikut's cara menghitung bahwa:

• Jumlah dari nilai yang mungkin dalam 64-bit integer adalah 263 – 1 = 9223372036854775807.
• Centang masing-masing mewakili 100 nanodetik, yang adalah 0,1 µs atau 0.0000001 s.
• Maksimum rentang waktu yang akan 9223372036854775807 ⨉ 0.0000001 s, sehingga ratusan milyar detik.
• Satu jam telah 3600 detik, satu hari telah 86400 detik, dan satu tahun 365 hari, sehingga ada 86400 ⨉ 365 s = 31536000 s dalam setahun. Ini adalah, tentu saja, hanya rata-rata, mengabaikan tahun kabisat, leap detik, atau setiap kalender perubahan masa depan postapocalyptic rezim mungkin mendikte pada sisa penduduk dunia.
• 9223372036854775807 ⨉ 0.0000001 s / 31536000 s ≈ 29247 tahun
• @corsiKa menjelaskan bagaimana kita bisa kurangi tahun kabisat: 29247 / 365 / 4 ≈ 20
• Jadi anda maksimal tahun ini 1601 + 29247 – 20 = 30828.

Beberapa orang memiliki benar-benar mencoba untuk mengatur ini dan datang dengan tahun yang sama.

[2]: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs. 85).aspx

Jika anda don't merasa buruk tentang beberapa menebak, biarkan saya memberikan sebuah penjelasan. Dan saya don't berarti "seseorang menetapkan nilai untuk omong kosong" yang's jelas selalu mungkin :)

Unix time biasanya menggunakan jumlah detik sejak tahun 1970. Windows, di sisi lain, menggunakan 1601 sebagai awal tahun. Jadi jika kita berasumsi (dan yang's besar asumsi!) yang masalah adalah salah konversi antara kedua kali, kita dapat membayangkan bahwa tanggal yang seharusnya diwakili sebenarnya <menyerang>kadang-kadang di 2011 (1970 + 41), yang punya salah dikonversi ke 1640 (1601 + 41)</strike>. EDIT: Sebenarnya, saya membuat kesalahan di Windows awal tahun. It's mungkin bahwa penciptaan sebenarnya waktu itu di tahun 2010, atau ada kesalahan lain yang terlibat (off-by-salah satu kesalahan yang cukup umum dalam perangkat lunak :D).

Mengingat bahwa tahun ini terjadi untuk menjadi yang lain dari pelacakan tanggal yang terkait dengan file tersebut, saya pikir itu's cukup penjelasan yang masuk akal :)

Seperti yang telah ditulis oleh orang lain, [Windows epoch di 1601-01-01 00:00][masa].

Jumlah detik antara zaman itu dan filetime ditampilkan, adalah 1.266.705.294. Jika kita menambahkan bahwa untuk Unix epoch, kami tiba di 2010-02-20 23:34:54 WIT, hari sabtu. Ini adalah sekitar satu tahun sebelum tanggal akses terakhir, yang membuatnya agak masuk akal. Jadi itu mungkin telah Unix timestamp ditafsirkan terhadap salah zaman.

Seperti biasa untuk pertanyaan jenis ini, Raymond Chen's blog memiliki jawaban mengenai hal ini dari "Mengapa Win32 epoch 1 januari 1601?" entri dari 6 Maret, 2009:

FILETIME struktur catatan waktu dalam bentuk 100 nanodetik interval sejak 1 januari 1601. Mengapa tanggal tersebut dipilih?

kalender Gregorian beroperasi pada 400-tahun siklus, dan 1601 adalah tahun pertama dari siklus yang aktif pada saat Windows NT sedang dirancang. Dengan kata lain, hal ini dipilih untuk membuat matematika datang keluar dengan baik.

aku benar-benar memiliki email dari Dave Cutler membenarkan hal ini.