 |
|
 |
Hey, what do you think guys? Do we really have to scratch our heads for what would happen thirty years hence? I personally feel that stuff like this would be best handled by then generation. Or they may not even have to deal with this head-ache! With the pace things are headed, I can tell from deep conviction that the current generation OSs will have phased-out by then. What happened to the Y2K fuss? It came to a pass with the turn of the millenium and I really don't know whether it had cast its "evil spell" on any enterprise/ individual.
BTW, Ruchit, I don't mean to poke fun at your article. Indeed, this was a good one. Nevermind.
|
|
|
|
 |
|
 |
What really do you think happened behind the media "Y2K fuss"? Me and tons of other programmers went through project after project and those few (of the projects I was responsible) that used date and time, was put through practical tests and analysis. Where problems were identified, amendments were made or the program/system was replaced with something else.
There is a good reason "nothing happened".
/rob
|
|
|
|
 |
|
 |
If any 32-Bit-application will still be running in 2038, they will fetch us out of the old-peoples-clinics and we'll be engaged for migration strategies, because nobody will be able to deal with ancient 32-Bit code.
But then: I do not believe that any application from today will still run then, OK, perhaps in a museum. Didn't they say that the sun also loses its light around that time
|
|
|
|
 |
|
 |
I am the author of some of the material that is presented here as someone else's work.
http://www.2038.org/ http://maul.deepsky.com/%7Emerovech/2038.html
He even linked to my site for the source code, but mysteriously decided not to credit it?!
Tsk, tsk, would it have hurt so much to give me a link?
Sincerely, William Porquet http://www.2038.org/ william@2038.org
|
|
|
|
 |
|
 |
Hi William,
I've used wikipedia for the gif reference and another site as well for code referencing. I've given the link in the article to the reference.
Please provide me with the reference of the web-page from where you think the content has been taken from.
I'M OF THE GENUINE OPINION TO GIVE AWAY PROPER CREDITS WHICH I'VE DONE BY LINKING AND MENTIONING IN THE ARTICLE.
Still, in this case I'd revise the article with your reference and ADD propoer credits.
sorry for the inconvinince.
Thanks,
Ruchit S.
Ruchit S.
******************************************
|
|
|
|
 |
|
 |
one more thing,
I had already done lot of research before writing this article. I needed some good tested program to simulate the problem, and there I found the pearl one , on your site. I guess linking makes it a difference , by giving a due credit to the original author.
We are doing quite a diff. work around here around the problem. I really had no intention to re-publish the cotnent of someone that's why it's been properly mentioned in the text with a ref.
Thanks.
Ruchit S. http://ruchitsurati.net
******************************************
|
|
|
|
 |
|
 |
Hello Ruchit,
I appreciate your prompt attention to this matter.
First of all, the language is "Perl", the semi-precious gem is a "pearl".
You quoted me verbatim with regard to the outputs, without so much as a set of quotation mark and a link. I suggest you correct this ASAP.
Sincerely, William
|
|
|
|
 |
|
|
 |
|
 |
Cool... or in 30 years we [that is MS] could just change the arbitrary date reference point from Jan 1, 1970 to say Jan 1, 2000.
I know, it's not as exciting -- but it would be a lot cheaper and easier.
In business, if two people always agree, one of them is unnecessary.
modified on Thursday, May 8, 2008 12:32 AM
|
|
|
|
 |
|
 |
The "Y2038 Bug" was well & truly acknowledged even while the press was beating up Y2K. There are 2 reasons why it doesn't get much press coverage now: 1) "All Consumer Electronics will Fail in 30 Years" is not much of a headline. 2) Y2K ended up being a complete fizzer, none of the expected catastrophes happened.
That being said, there's a couple of other points to note in your article:
Solution 2 has many more short-comings than merely postponing the inevitable: for one thing, it's got to applied in context, e.g. Birth dates: there are an awful lot of people still kicking around that were born before 1970.
Doesn't solution 3 (shift from 32 - 64 bit architecture) suffer the same problems as solution 1 (redefine the time_t structure as 64 bit)? After all, it's serialisation/storage that is the real issue. Simply redefining time_t (which is actually a typedef not a struct) would introduce fewer complications than porting the entire code base from 32 to 64 bit (pointer and array index sizes, sizeof(xxx) changes ...). Any coder that performs serialisation in this day & age without including some form of version identification (which would indicate whether 32-64 bit time_t conversion needs to be performed) should be summarily shot anyway . Even embedded systems' firmware upgrades should/could check the previous firmware version & perform the necessary conversion(s).
Fortunately, most RDBMS's have been using 64-bit date/time as standard for many years (e.g. ODBC's DATE type - typedef'd from a double or 64 bit floating point number on 32 bit systems) so the Y2038 is likely to turn out more of a fizzer than even Y2K.
T-Mac-Oz
|
|
|
|
 |
|
 |
This is valuable information to keep in mind. It would be interesting if you could add some further notes about what steps software vendors are taking, or what the IT press is reporting.
|
|
|
|
 |
|
 |
Considering the first PC was introduced less than 30 years ago sporting a single floppy drive and 64K RAM, and considering how far technology has come in that time... addressing a date problem 30 years future seems a bit like a company in the 1920's beginning work on a prototype buggy whip to be introduced in the 1950's ... or scientists addressing a problem the world will face 30 million years from now.
In the world of technology 30 years is an eternity. I guess the topic has some academic interest, and the article is fairly well written -- but it has no practical value (IMO).
In business, if two people always agree, one of them is unnecessary.
|
|
|
|
 |
|
 |
Douglas R. Keesler wrote: In the world of technology 30 years is an eternity. I guess the topic has some academic interest, and the article is fairly well written -- but it has no practical value (IMO).
I agree completely. I think, if the ANSI C program (discussed in the article) is, for some reason, being used in the year 2038, we will need to worry more about that.
Nobody can give you wiser advice than yourself. - Cicero .·´¯`·->Rajesh<-·´¯`·. Codeproject.com: Visual C++ MVP
|
|
|
|
 |
|
 |
Disagree (but just a little) - there's a lot of C code out there, and I'll be betting that some will still be running in 30 years time. You'll find it in the IS shops where you get the sort of "we can't replace it because we don't have the source code" comment from the "If it ain't broke don't fix it" type of IS managers - i.e. those that don't want to learn anything new because "all the best stuff has already been invented" and "a GUI is for wimps".
I am convinced that lobotomising users will make little to no difference.
|
|
|
|
 |
|
 |
Hi Douglas,
I completely agree with you. This is more of an acedemic value and I'm a firm believer that we'll never come across this practical situation.
By the year 2038, all system would be migrated to 64bit architecture or above, which by default solves the problem.
The motive behind writing this article, is just to explore thought over a possibility.
What do you say ?
Thanks.
Ruchit S. http://ruchitsurati.net
******************************************
|
|
|
|
 |
|
 |
Of course, there are 30 more years if you just want to display the current date. Some sort of simulation software, or other magical voodoo prediction tools might encounter such problems years before that date. At least if they use time_t for such future dates.
It's good to have read about that, since I wouldn't even have thought of checking how far time_t goes.
|
|
|
|
 |
|
 |
Once I read from CodeProject daily news. IIRC, some insurance banks already encounter this problem for new insurances to be paid for 30 years. Or is it 30 years house loans? Couldn't remember.
|
|
|
|
 |
|
 |
That's nonsense. First, this issue is not a "bug" -- it is simply a limitation of the "system" time function. Thus any code functions deriving from system time (such as CTime, time_t, etc) will bear this limitation... but I'm sure you are aware that COLEDateTime handles dates/time from Jan 1, 100 - December 31, 9999.
This issue is strictly with the system clock and has nothing to do with the ability of software developers to write date dependent software such as mortgage/loan amortizations etc... or to do far future date calculations.
In business, if two people always agree, one of them is unnecessary.
|
|
|
|
 |
|
 |
It was this kind of attitude that caused the rush to fix the y2k problem at the last miunnute back in 1999.
Look how long it took before action was taken to correct the September 9,1999 date problem (9999), the Y2K problems? There were warnings of these problems years before it became a big priority to fix them.
There are still many companies that have not converted to the 4 digit representation for the year which causes another problem until the year 2032 (08/06/25) - 2008 ? 2025?
I wouldn't count on the y38k problem to be solved anytime soon based on the previous history of simular problems unless these warnings are taken seriously now and fixed now.
|
|
|
|
 |
|
 |
robertjb20 wrote: It was this kind of attitude that caused the rush to fix the y2k problem at the last miunnute back in 1999.
Right... and the Y2K problem was devastating, eh?
robertjb20 wrote: There are still many companies that have not converted to the 4 digit representation for the year
So what? It doesn't matter how the date is displayed, it only matters whether the software knows what the date is internally and can compute it properly.
robertjb20 wrote: I wouldn't count on the y38k problem to be solved anytime soon
And it doesn't need to be solved anytime soon.. And like Y2K, it's not a "bug" -- it's simply a limitation of System Time. Right now, system time stores times as seconds elapsed since Jan 1, 1970. Fine! In 2030 if we are still running 32bit systems, then make time a value of seconds elapsed since Jan 1, 1990. That's was a toughie, eh?
Because System Time bears this limitation doesn't mean software developers can't write code that handles future dates. If you are a C++ developer look at COLEDATETIME in your MSDN -- it already handles dates/times from Jan 100 to December 9999. If that's not good enough you could always write your own date/time management class.
Look banks and major corporations aren't buying $19 shareware apps to manage their data. They use software developed by "real" programmers, who don't tie their code to the limitations of the system clock. What a novel idea!
In business, if two people always agree, one of them is unnecessary.
|
|
|
|
 |
|
 |
Agreed. With the availability of 64-bit systems to even home users right now, it seems that this won't be an issue in 30 years. Especially in critical applications.
|
|
|
|
 |
|
 |
I fully agree, are we still using 32-bit processors in 2038? And when we're in 2038 are we still using software from today?
|
|
|
|
 |
|
 |
This seems to be good at first look, but this would just delay(post-pone) the judgement day to the year 2106 as it will give some more scope by adding another usable bit. You will be in the same trouble by then.
I pretty much doubt that I will be in trouble in 2106 (or any other of the current CP users)... that would make me 126 years old
|
|
|
|
 |
|
 |
2106,almost 100 years.I think we will found a perfect solution before that . maybe people at that age would use another operation system.And a very clearly thing we will see,our software maybe down long before that.
|
|
|
|
 |
|
 |
2106? By then legacy systems will be 256-bit, and 32/64-bit will only appear on whatever becomes of Wikipedia
|
|
|
|
 |