On another board, I got this “helpful tip” passed on by a concerned friend:
This reeks of UL. For one thing on the same regional settings page, is a long date format with a 4-year date. I have to believe that the short date format is just that- how you would like dates displayed, and has nothing to do with how the processor keeps track of time.
I tried going to Microsoft’s homepage, & found more info than I cared to know about Y2K, but nothing mentioned about this. I do not choose to pay Microsoft $35 to sort this out, so I am turning to the collective intelligence on this board for help - thanks in advance!
If I’m not mistaken, all Microsoft products think of the date the same way, that of a single number with several digits. Every increase of “1” means the next day. Likewise, the time is kept as a fraction (decimals) of the number. (I know that this is the way Excel thinks.) If this is the case with all Microsoft products, then the year will not be a problem, the software doesn’t care what year it is.
Of course, there could be a problem on some programs when entering a date, since the program won’t know if you mean “1900” or “2000”. But the internal clock shouldn’t have a problem.
BTW, Microsoft’s update website has been posting several free downloadable patches to fix other Y2K problems. You might want to check that out.
This is so stupid. I’m sure that there isn’t anything to it.
As it says right in the Regional Settings window:
“Many programs support international regional settings. Changing the Regional Settings affects the way these programs display and sort dates…”
So it is an aesthetic effect for when dates are displayed. I have no doubt that it is nothing more than that. C and C++ programs, which are still the dominant languages, receive time from the system as a large number of seconds, so the change of a year is really just another second passing.
And I would expect that even this is a display/sorting issue rather than a real Y2K prob. So, perhaps if you sort by date, your files created in 2000 will show up as the oldest files…
The Microsoft Y2k website (www.microsoft.com/y2k) will provide everything you need to know about compliance with they Y2k problem.
TO answer the question, simply changing a date format in the control panel will not ensure y2k compatibility. If the date works on a 4 or 2 digit scale by changing an option, then the OS is obviously compliant, as it recognises the 4 digit date with no problem.
Many pieces of software may continue to use the 2 digit format, the only caveat for compliance is it will recognise and store the data consistant with a 4 digit format. Display and storage are 2 different issues all together.
With this said, I have copied this information from the Microsoft y2k site:
“Sherlock Holmes once said that once you have eliminated the
impossible, whatever remains, however improbable, must be
the answer. I, however, do not like to eliminate the impossible.
The impossible often has a kind of integrity to it that the merely improbable lacks.”
– Douglas Adams’s Dirk Gently, Holistic Detective
This bit of info is only applicable to applications that use the regional settings for the date functions since there are several areas on a computer that you can pull date/time functions from.
After a bit of playing around with the system functions used by the software we make, I determined a few things:
the “start” date for this representation of dates as seconds since… longints is 00:00:00 GMT, Jan 01, 1970.
You can’t use this for dates after January 18, 2038.
This is an industry-wide limitation, apparently. I could find a good answer for this if anyone really cares, but since I’m hassling the developers for slipping timelines at the moment anyway, I don’t want to bother them and our QA department doesn’t know.
Using dates past this is not a problem (I just tested it) so I don’t think that the world will end on January 19, 2038, but on the off chance that some very old software is kicking around then, it may experience a few hiccups.
Eris, you might discover that the fix for the limit to 2038 requires a fairly simple change of the time integer to an unsigned long, rather than a signed one. Not that it is important, since hopefully no one will be using MS in 2038.
>>Being Chaotic Evil means never having to say your sorry…unless the other guy is bigger than you.<<
Eris:
UNIX system perhaps?
Perhaps there are other C compilers that are the same way, but that is certainly the common way for most unix flavors to be.
Narile:
No. Converting to unsigned would be bad. You’d lose all dates prior to 1970.
The solution:
Change longs to 64-bit and recompile.
LOL!! Well, at least on my system (linux 2.0.36), there are data types called “long long” and “unsigned long long” which are 64-bit, so it would prolly be easier to change the typedef of time_t to “long long”
I certainly don’t want to interrupt a useful dialogue, but do want to say thanks to all who have contributed. It sure sounds like the Y2K problem requires a user/system-unique solution, so my suspicions regarding a “one-size-fits-all” solution were well-founded.
I also have Windows at work, where the techies have placed a smiley sticker with “Y2K compliant” on it on my computer, and it still displays short dates with 2 years only, so I don’t think that needs to be changed.
No, Eris is right. The Windows API time call, and the MFC CTime class also uses Jan. 1, 1970 as the epoch (beginning date). (It’s not Jan. 1, 1980 as speculated earlier in this thread.) Microsoft isn’t known as an innovator. They based most of these routines on C libraries that already existed for UNIX. That was the right thing to do, but it means that many Windows programs, as well as UNIX programs will be in trouble in Y2038.
They were at once her reason for life and her reason for despair.
– Eris, on programmers.
I suspect we’ll see a gradual conversion to 64-bit longs. Alphas (well at least OSF and Linux for Alpha) already use 64-bit longs in their standard libraries. I expect that this will slowly spread throughout other unix flavors, causing an occasional bug. I already ran into a bug of this sort when porting some of my ex-boss’s codes from IRIX to OSF, because he used LONG_MAX in a way that caused a logic error with 64-bit longs.
And who knows. Mebbe in 20 years or so, we’ll see the equivalent happen in the MS world.
Whatever - this is NOT something I’m going to lose sleep over. In 2038 I’ll be 65 years old. If all goes according to plan, my personal interstellar conveyance with which I will have left the planet some 10 or 15 years prior to this bug happening will be certified Y2038-compliant. (Although you never know, that toaster I’ll have brought along with me might malfunction horribly…)
And thanks for the tips, guys, but according to our QA people this issue isn’t exactly a top priority for us right now!
(BTW, if all goes well in the current internal trial that the IRS is running with our forms software, by the time this bug hits, everyone in the US will be filing their income tax returns with our InternetForms! Which currently AREN’T Y2038 compliant! So wait 38.5 years, file just before January 18, and you MAY be able to put one over on the IRS! Cool, huh?)
I’m sure that there isn’t anything to it.