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