up vote 0 down vote favorite
share [g+] share [fb]

I was debating about the 2038 bug on unix with a friend (the 32 bit timestamp bug).

We were actually wondering on how windows store the dates itself ? I was thinking it was a simple DateTime but how would the system be able then to calculate the delta between two dates ?

Is it possible then that windows stores dates (internaly) in a timestamp then converts it in a DateTime ?

link|improve this question
feedback

1 Answer

up vote 4 down vote accepted

There is FILETIME, which is 64 bit signed int, representing 100 nano second intervals since Jan 1, 1601. This lasts a ridiculously long time, since 64 bits is a huge number.

Whereas CTIME (Unixtime) is a signed 32 bit int, representing seconds since Jan 1, 1970.

The better question is, "WHERE" does Windows use each format? Every single thing that stores time, potentially can use any time representation they want too.

Does AD use the same as the system, as the file system, etc? Be interested in the answer to that one!

link|improve this answer
As far as I know, at least the .NET Framework picks up the time from filetime. – Fredrik Mörk Jul 15 '09 at 19:03
So it is stored also as 1234567890 if I understand correctly ? – Erick Jul 15 '09 at 19:40
@Erick: that looks like CTIME, not FILETIME. FILETIME is into crazy numbers. Right now is: 1247703464 in CTIME and FILETIME for right now is: 1289217709140600000 – geoffc Jul 16 '09 at 0:18
Windows has at least two or three different ways of storing a time. FILETIME is the one used by the NTFS folks, then there is OLEDateTime, which is a double where integral part is the day and the fractional part the time of day and somewhere else (don't remember the name right now) a human-readable character string, storing date, time and time zone. – Joey Aug 8 '09 at 7:33
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.