Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

home / study / questions and answers / engineering / computer science / y2k revi

ID: 671015 • Letter: H

Question

home / study / questions and answers / engineering / computer science / y2k revisited the end of time decades ago, programmers ...

Question

Y2K revisited
the end of time
decades ago, programmers trying to conserve valuable storage space shortened year values to two digits. this shortcut created what became known as the "Y2K"problem at the turn of the century.programmer needed to review billions of lines of code to ensure important programs would continue to operate correctly. the "Y2k"problem merged with the dot-com boom and created a tremendous demand for information technology employees. information system users spent billions of dollars fixing or replacing old software.the IT industry is only now beginning to recover from the post boom slump. could such hysteria happen again? it can and , very likely , it will.
today most programs use several different schemes to record dates.one scheme, POSIX time, widely employed on UNIX based systems,requires a signed 32 bit integer to store a number representing the number of seconds since January 1, 1970."0" represents midnight on January 1,"10" represent 10 seconds after midnight.a simple program then converts these date into any number of international date formats for display.this scheme works well because it allows programmer to subtract one date/time from another date/time and directly determine thhe interval between them. it also requires only 4 bytes of storage space.but 32 bits still calculates to finite number, whereas time is infinite. as a business manager, you will need to be aware rom repeating history. the following question will help you evaluate the situation and learn from history
a) if 1 represent 1 second and 2 represent for 2 seconds, how many seconds can be represented in a binary number 32 bit long? use a spreadsheet to show your calculations

Explanation / Answer

It is now clear that any solution to Y2K38 problem is neither trivial nor obvious. Every solution and suggestion has its pros and cons and in most of the cases, it is not feasible too. The most robust solution, which can be thought of now, seems to be bringing in the 64-bit OS. But as already mentioned, there are many applications, which need information of many years ahead of now, like loans, bonds, etc. For such applications, we provide here some solution that can minimize or possibly eliminate the risk of erroneous calculations. In the following paragraphs, we try to explain a possible solution to tackle Y2K38 problem.

Working Paper No.9 – Y2K38 9

The proposed solution makes use of a header file, which is to be included in the source code of the application followed by recompilations to get the executable. However, this solution is applicable to only those applications whose source code is available in hand. After these modifications, the application software is Y2K38 compliant.

The solution is intended for the codes, which make use of the time function gmtime() and gmtime_r(). The gmtime() and gmtime_r() functions convert a time in seconds since the Epoch (00:00:00 UTC, January 01, 1970) into a broken-down time, expressed as Coordinated Universal

Time (UTC). These function definitions are given as follows:

------------------------------------------------------------

#include <time.h>

struct tm *gmtime(const time_t *clock); //where clock is the time to be converted.

-----------------------------------------------------------

#include <time.h>

struct tm *gmtime_r(const time_t *clock, struct tm *result);

where clock is the time to be converted and result points to the structure where the converted

time is to be stored.

-----------------------------------------------------------

Any piece of code that makes use of above functions will fall prey on 19-Jan-2038, 03:14:07 AM

GMT. But the danger can be avoided, if we replace the above functions, with the function defined, in the header file mentioned above. The prototype of the new function, called as pivotal_gmtime_r(), is as follows:

-----------------------------------------------------------

struct tm *pivotal_gmtime_r (const time_t *now, const time_t *future, struct tm *result);

where now is the current time, which can be obtained by calling time(&now) function, future is any time in future (beyond 2038) and result is the pointer to the structure, where the converted time is to be stored.

-----------------------------------------------------------

We have seen that maximum value of time_t variable is 2,147,483,647 i.e. 19-Jan-2038, 03:14:07 AM GMT. Therefore any program, which makes use of it should yield an unexpected date at time_t := 2 147 483 648. Now if we can show that by using the above defined function, the date beyond 19-Jan-2038, 03:14:07 AM GMT i.e. date for which time_t: = 2 147 483 648 or greater than this, the problem of Y2K38 can be solved for some specific codes. The following is the example of the code, which does the same.

-----------------------------------------------------------

#include <stdio.h>

#include <time.h>

#include "pivotal_gmtime_r_c.h"

int main()

{

struct tm *tm_ptr;

time_t now, beyond2038;

time(&now);

beyond2038=2147483641;

for(;beyond2038<2147483651;beyond2038++){

Working Paper No.9 – Y2K38 10

pivotal_gmtime_r(&now,&beyond2038,tm_ptr);

printf("Date: %04d-%02d-%02d ",tm_ptr->tm_year+1900,

tm_ptr->tm_mon+1, tm_ptr->tm_mday);

printf("Time: %02d:%02d:%02d ",tm_ptr->tm_hour,

tm_ptr->tm_min, tm_ptr->tm_sec);

}

exit(0);

}

It is clear from the code that the last 3 iterations for the variable beyond2038 should produce some unexpected date (i.e. some date in year 1901), if the code is not Y2K38 compliant. Otherwise the output of the code should give the correct date i.e. 19 Jan2038, 03:14:08 AM GMT and so on. The following is the output of the program on Linux 2.4.20-8.

-----------------------------------------------------------

Date: 2038-01-19 Time: 03:14:01

Date: 2038-01-19 Time: 03:14:02

Date: 2038-01-19 Time: 03:14:03

Date: 2038-01-19 Time: 03:14:04

Date: 2038-01-19 Time: 03:14:05

Date: 2038-01-19 Time: 03:14:06

Date: 2038-01-19 Time: 03:14:07

Date: 2038-01-19 Time: 03:14:08

Date: 2038-01-19 Time: 03:14:09

Date: 2038-01-19 Time: 03:14:10

-----------------------------------------------------------

It is clear that the new function has made the code Y2K38 compliant. The date is calculated correctly even after the current limit of the variable time_t.