How to recognize different types of sentinel timestamps from quite a long way away

Raymond Chen


Some time ago, I discussed several timestamp formats you might run into. Today we’ll take a logical step from that information and develop a list of special values you might encounter. Note that if you apply time zone adjustments, the actual timestamp may shift by up to a day.

January 1, 0001The value 0 as a CLR System.DateTime.
January 1, 1601The value 0 as a Win32 FILETIME.
December 29/30, 1899The value -1 or 0 as an OLE automation date.
December 13, 1901The value 0x80000000 as a time_t.
December 31, 1969
January 1, 1970
The value -1 or 0 as a time_t.
January 1, 1980The beginning of the DOS date/time era. (Unlikely to be encountered since 0 is not a valid DOS date/time value.)
January 19, 2038The value 0x7FFFFFFF as a time_t.
February 7, 2106The value 0xFFFFFFFF as a time_t.
September 14, 30828The value 0x7FFFFFFF`FFFFFFFF as a FILETIME.

All of these special values have one thing in common: If you see them, it’s probably a bug. Typically they will arise when somebody fails to do proper error checking and ends up treating an error code as if it were a valid return value. (The special values 0, -1, and 0xFFFFFFFF are often used as error codes.)


Comments are closed. Login to edit/delete your existing comments