July 1998

Between two comets on a cataclysmic collision course to Earth, a gargantuan green monster the size of Times Square, and Mayor Giuliani's latest mandate that all New Yorkers wear daytime running lights, we wonder what other disasters are hurtling our way. If you listen to the mainstream media, the worst impending crisis is the Y2K problem—second only to El Niño in its ability to wreak havoc. But as programmers, we're already girding our loins for a wider variety of year-wrap issues looming in our future.        First, the C SYSTEMTIME structure provides the year since 0 AD—umm, we mean 0 CE—in a word-sized member. (We like it when politically correct year nomenclature just happens to match the latest Microsoft product terminology.) That means there's 63,538 more years until it's a problem. We can live with that. Next there's the FILETIME structure, a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601. Still no problem yet; by our calculations this gives us 58,000 or so years to update our code. How about OLE Automation? The COleDateTime class uses the DATE variant to handle dates from January 1, 100, to December 31, 9999. OK, we're cutting it a little close, but it's still not something we're likely to confront before retirement.        But what about time_t? The C runtime uses the time_t structure upon which MFC's CTime class is based. The time_t structure is actually a long integer that contains the number of seconds elapsed since Midnight, January 1, 1970. A signed long integer maxes out at 231 - 1, or 2,147,483,647 seconds, which equates roughly to 68 years. Added to 1970, that takes us only to 2038!        Not to be left out, Visual Basic has a date oddity. It handles dates well into the next millennium, but there's an interesting anomaly with the CVDate function (which converts strings to date values). Somewhere in the conversion from string to date and back, the default formatting is different for this century and next. Huh? Try it— load Visual Basic and put a button on a form, then add two labels. Next add these lines to the button's click handler: Label1 = CVDate("Jan 15, 2075") Label2 = CVDate("Jan 15, 1999")        Label1 will show "1/15/2075." Label2 will show "1/15/99." Not exactly consistent.        For help on these thorny issues, check out the Microsoft Year 2000 Resource Center at http://www.microsoft.com/y2k. Just one of the many guidelines given: an app must recognize dates into the 21st century through the end of year 2035. Why three years before 2038? Will it take that long to work out the bugs? Are we expecting some CPU anomaly? Or will Bellus simply obliterate life on Earth before 2038, eliminating the need for further fixes?        Speaking of obliteration, in honor of COM's fifth year on the planet, we felt the need to jettison the name of Don Box's ActiveX/COM column to the more appropriate House of COM. (As for whether the House of COM is apartment-threaded, only Don knows.)        And last but certainly not least, we want to announce that, starting with the July 1998 issue, our sister magazine Microsoft Interactive Developer (MIND) and MSJ will both be published by Miller Freeman. We look forward to the improved coverage and service we can provide by having both mags under one roof. — J.F. From the July 1998 issue of Microsoft Systems Journal