Hello
-currently supported core OS and mainstream support products operate as designed and with no known negative impact with regards to the 2038 unless otherwise noted.
-SYSTEMTIME has no problems and can go until the year 30,827.
-FILETIME, a 64-bit integer (two DWORDs representing LOW and HIGH values) since January 1, 1601 (Julian). It too can represent a 30,000 (or 60,000 unsigned) year interval.
Programs that are compiled with VC8 or newer and do not define _USE_32BIT_TIME_T are immune to Year 2038 problems caused by time_t, assuming that they do not contain bugs themselves (casting a time_t to an int and back will truncate it). I’m told by the Developer division that…
VC7.1 (Visual Studio 2003) contained __time64_t (see http://msdn2.microsoft.com/en-us/library/1f4c8f33(VS.71).aspx ), but developers had to specifically use it. (It appears that VC6 did not contain __time64_t – see http://msdn2.microsoft.com/en-us/library/aa272948(VS.60).aspx – but VC6 is no longer supported, unlike VC7.1.)
we expanded time_t to 64 bits by default in VC8 (Visual Studio 2005). See http://msdn2.microsoft.com/en-us/library/ms235429(VS.80).aspx. Also see http://msdn2.microsoft.com/en-us/library/w4ddyt9h(VS.80).aspx, which explains that _USE_32BIT_TIME_T is provided for backwards compatibility.
--If the reply is helpful, please Upvote and Accept as answer--