Another look at the year 2038 problem
I was asked last week (again) for guidance I could give (being involved in time in one way or another, in addition to my day job) on how Microsoft products may be impacted by the 2038 issue.
As I noted in January, the Year 2038 problem (as defined by the Wikipedia entry)...
"The year 2038 problem (also known as "Unix Millennium bug", "Y2K38," "Y2K+38," or "Y2.038K" by analogy to the Y2K problem) may cause some computer software to fail before or in the year 2038. The problem affects Unix-like operating systems, which represent system time as the number of seconds (ignoring leap seconds) since 00:00:00 January 1, 1970.[1] This representation also affects software written for most other operating systems because of the broad deployment of C. On most 32-bit systems, the
time_tdata type used to store this second count is a signed 32-bit integer. The latest time that can be represented in this format, following the POSIX standard, is 03:14:07 UTC on Tuesday, January 19, 2038. Times beyond this moment will "wrap around" and be represented internally as a negative number, and cause programs to fail, since they will see these times not as being in 2038 but rather in 1901. Erroneous calculations and decisions may therefore result.
Some people believed that the bulk of issues would surface on January 19, 2008, the date when new 30-year mortgages and bonds could be impacted. In fact, much of the impact would have been seen years ago given that there are many financial instruments with a greater than 30 year life span: some mortgages and bonds extend out 40 years, and there are Japanese and English mortgages that can span close to a century.
From what I understand (thanks to the education from Geoff, Shay and several folks in DevDiv), information on how to mitigate the year 2038 bug was included in our Y2K response in the late 1990's. And Microsoft has provided guidance and statements on our various web sites, as impacts have generally been product specific for older products no longer in support (unless otherwise indicated in a supporting KB article).
In general…
- 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.
- Difficulties will be found were developers use C/C++ time_t, which will run out in 2038.
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 https://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 https://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 https://msdn2.microsoft.com/en-us/library/ms235429(VS.80).aspx. Also see https://msdn2.microsoft.com/en-us/library/w4ddyt9h(VS.80).aspx, which explains that _USE_32BIT_TIME_T is provided for backwards compatibility.
For more references...
- This link for MSDN and TechNet. Also, please see this article on MSDN from 1998 on the issue.
- See this ink for references on Microsoft.com
Hope this helps.
Tags: Microsoft, Vista, Windows, Time, 2038.
Comments
Anonymous
April 21, 2008
PingBack from http://microsoftnews.askpcdoc.com/?p=3599Anonymous
April 30, 2008
Thanks for posting this info. I'm sure it will be useful to those before 2038.