|Date:||September 5, 2003 / year-entry #47|
|Summary:||The great thing about timestamps is that there are so many to choose from.|
The great thing about timestamps is that there are so many to choose from. Sometimes, while debugging (or reading incomplete documentation) you'll find a timestamp and wonder how to convert it into something readable. Here are some tips.
We will use November 26, 2002 at 7:25p PST as our sample time.
UNIX timestamps are in seconds since January 1, 1970 UTC. It is a 32-bit number, the only 32-bit number in common use as a timestamp.
November 26, 2002 at 7:25p PST = 0x3DE43B0C.
If it's a 32-bit value starting with "3", it's probably a UNIX time. (The "3" era began in 1995 and ends in 2004.)
To convert these values to something readable, you have several choices.
The C runtime time_t value is the same as a UNIX timestamp, so you can use the
This is the time format used by the C runtime and by the Windows NT event log.
Number two: The Win32 FILETIME
Win32 FILETIME values count 100-nanosecond intervals since January 1, 1600 UTC. It is a 64-bit number.
November 26, 2002 at 7:25p PST = 0x01C295C4:91150E00.
If it's a 64-bit value starting with "01" and a letter, it's probably a Win32 FILETIME. The "01A" era began in 1972 and the "01F" era ends in 2057.
To convert these values to something readable, you can use the
Number three: The CLR System.DateTime
Warning: Actual .NET content (I'm sorry). CLR System.DateTime values count 100-nanosecond intervals since January 1, 1 UTC. It is a 64-bit number. These aren't used much yet.
November 26, 2002 at 7:25p PST = 0x08C462CB:FCED3800. (? somebody check my math)
If it's a 64-bit value starting with "08" and a letter, it's probably a CLR System.DateTime. The "08A" began in 1970 and the "08F" era ends in 2056.
To convert these values to something readable, construct a System.DateTime object passing the 64-bit time value as the constructor parameter.
Number four: The DOS date/time format
The DOS date/time format is a bitmask:
24 16 8 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |Y|Y|Y|Y|Y|Y|Y|M| |M|M|M|D|D|D|D|D| |h|h|h|h|h|m|m|m| |m|m|m|s|s|s|s|s| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ \___________/\________/\_________/ \________/\____________/\_________/ year month day hour minute second
The year is stored as an offset from 1980. Seconds are stored in two-second increments. (So if the "second" value is 15, it actually represents 30 seconds.)
These values are recorded in local time.
November 26, 2002 at 7:25p PST = 0x2D7A9B20.
To convert these values to something readable, convert it to a FILETIME via DosDateTimeToFileTime, then convert the FILETIME to something readable.
Number five: OLE Automation date format
The OLE automation date format is a floating point value, counting days since midnight 30 December 1899. Hours and minutes are represented as fractional days.
Converting among these formats
Often there is no direct conversion between two formats; you will have to go through some intermediary formats.
Let's see if I can draw a little chart.
I'm not sure that chart actually cleared up anything.
If you allow yourself to use MFC, then there are some more conversions available.
I won't bother trying to add these (unidirectional) arrows to the chart above.
Brad Abrams' blog followed some of these arrows and produced a cute little formula to convert UNIX time_t directly to System.DateTime.
Other time formats
JScript's Date object constructor can construct from an integer representing milliseconds since 1970. This is the same as UNIX time, just multiplied by 1000.
<-- Back to Old New Thing Archive Index