Linux - NewsThis forum is for original Linux News. If you'd like to write content for LQ, feel free to contact us.
All threads in the forum need to be approved before they will appear.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This is not a very serious problem. Apparently it has to do with the standard C library time.h.
A reimplementation of time.h file would solve it. Then of course, recompiling existing applications which use time.h with the new version of the library.
Quote:
From the original article This problem is somewhat easier to fix than the Y2K problem on mainframes, fortunately. Well-written programs can simply be recompiled with a new version of the library that uses, for example, 8-byte values for the storage format. This is possible because the library encapsulates the whole time activity with its own time types and functions (unlike most mainframe programs, which did not standardize their date formats or calculations). So the Year 2038 problem should not be nearly as hard to fix as the Y2K problem was.
Last edited by vharishankar; 04-04-2005 at 10:03 PM.
Originally posted by Harishankar This is not a very serious problem. Apparently it has to do with the standard C library time.h.
A reimplementation of time.h file would solve it. Then of course, recompiling existing applications which use time.h with the new version of the library.
i do not understand how do u intend to o solve the given problem
We cannot solve it. It's the programmers who developed the C libraries who would solve it.
We must merely recompile existing programs which use the time library against a new version of time.h which allows for large integers to be stored in the time data.
Current time.h has a limitation. Currently the format used by time.h is being stored in terms of seconds since Jan 1, 1970. In 2038, the integer would overflow because of the limitation of the integer data type.
Once the library is changed to accomodate integer from 4 bytes to 8 or 16 bytes, then the problem is solved.
Existing applications have to merely recompile against the new version of the library. That's all.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
