Is Unix time end by 2038
In 32 bit operating system, Dates are calculated using number of seconds differece between 1 January 1970 and current date. This difference will reset to 00:00:00 on January 2038. This is called year-2038 Bug.
We all are aware of Y2K bug. In the code, two digit was used for storing date. Say for the year 1980, only 80 will be stored. This created issue when the year turned 2000. Storing 00 for year created confusion whether it is 1900 or 2000?
year-2038 Bug is of serious in nature. We have almost 18 years time available to fix but for few programs, which deals with future dates will end up in problem much earlier. Consider a licensing component in the program, which sets the validity of the usage. If the license is valid for more than 18 years tben the date calculation will go wrong and the User will not be allowed to use the product. This is just an example. Those who are using future dates, should wake up and start thinking the alternative way.
What is the solution? Most of the blog suggest to use 64 bit. If you are planning to migrate your App to 64 bit in near future then this would be the best choice. If not, try different kind of logic rather than storing and manipulating with the dates. In the above licensing example, try storing the Installed date and the number of years to use the product, rather than storing the end date.
Store the date as string and manipulate the DD, MM and YYYY components separately. Build your own logic, rather than depending on the date and time functions.
Another approach would be to use 64 Bit date type in database and also in your program. Recent compiler and DB has this support. MySQL has DATATIME and TIMESTAMP data type. DATATIME stores date till '9999-12-31 23:59:59' and TIMESTAMP has range of '1970-01-01 00:00:01' UTC to '2038-01-09 03:14:07'.
Further reading:
http://en.wikipedia.org/wiki/Unix_time
http://2038bug.com/index.php/articles/39-developer/61-what-can-i-do-as-a-developer
We all are aware of Y2K bug. In the code, two digit was used for storing date. Say for the year 1980, only 80 will be stored. This created issue when the year turned 2000. Storing 00 for year created confusion whether it is 1900 or 2000?
year-2038 Bug is of serious in nature. We have almost 18 years time available to fix but for few programs, which deals with future dates will end up in problem much earlier. Consider a licensing component in the program, which sets the validity of the usage. If the license is valid for more than 18 years tben the date calculation will go wrong and the User will not be allowed to use the product. This is just an example. Those who are using future dates, should wake up and start thinking the alternative way.
What is the solution? Most of the blog suggest to use 64 bit. If you are planning to migrate your App to 64 bit in near future then this would be the best choice. If not, try different kind of logic rather than storing and manipulating with the dates. In the above licensing example, try storing the Installed date and the number of years to use the product, rather than storing the end date.
Store the date as string and manipulate the DD, MM and YYYY components separately. Build your own logic, rather than depending on the date and time functions.
Another approach would be to use 64 Bit date type in database and also in your program. Recent compiler and DB has this support. MySQL has DATATIME and TIMESTAMP data type. DATATIME stores date till '9999-12-31 23:59:59' and TIMESTAMP has range of '1970-01-01 00:00:01' UTC to '2038-01-09 03:14:07'.
Further reading:
http://en.wikipedia.org/wiki/Unix_time
http://2038bug.com/index.php/articles/39-developer/61-what-can-i-do-as-a-developer