This Story Posted:
February 12th

 
 

Follow-Up
[11:26 AM]
Y2K On NeXTStep/OpenStep Explained
In our story entitled "NeXTStep, OpenStep Not Y2K Compliant, Mac Is," we asked for NeXTStep, Rhapsody, and OpenStep developers to explain why there was a problem with the operating systems. We had many Observers write in to do just that and we are sharing those responses with you. The following two letters are typical examples of the great responses we received. Gerben Wierda tells us the fault lies in the way that Unix counts time.

"Your wrote that you like to hear about Y2K and NEXTSTEP/OPENSTEP. Why aren't these Y2K compliant? After all, they are newer than MacOS, which *is* Y2K compliant.

The answer is simple: the basic OS in NEXSTEP and OPENSTEP *is* Y2K compliant. There is a basic problem in both operating systems, that is shared by most if not all current Unix-like operating systems: the time function has a Y2k38 problem, or in other words, somewhere in 2038, this second counter will roll over just like the two digit year counter is doing on other systems.

However, not all applications are Y2K compliant. Most of them interface to this second counter with date settings and displayings, some of those will not be Y2K compliant. There will be (in some cases there already are) patches for these.

Yours,

--Gerben Wierda"

David Weintraub goes a bit farther to and talks about command lines, and programming mindsets.

I found your article that NextStep and OpenStep are not Y2K compliant, interesting. The date routines in Unix are based on the number of seconds since January 1, 1970. Several system calls convert the date from the number of seconds into standard units of various sorts. In fact, all Unix system clocks are set to GMT, and the routines convert the date and time to local time if desired. Since the year isn't the issue, you'd think that Y2K compliance would be a cinch.

However, that King of Unix, Solaris, was originally not Y2K compliant (although it is now). What threw Solaris off were some very minor glitches. When Solaris is booted and the date is set, you cannot enter more than two digits for the year. Also, several other places always assumed that a two digit year is always a year in the 20th century. The fix was minor, but it just shows you how hard it can be to be Y2K compliant.

For example, in Unix date routines, the year is returned as the year minus 1900, so this year is "99" in Unix, and next year will be "100". The whole system works fine if you add 1900 to the date. However, if you simple prefix 19 to the date, this year will display as 1999, but next year will be 19100. In the Unix man-pages, this is very well documented, but you wouldn't believe the number of programs I have seen that simply displayed a "19" in front of the date. It just can show you that the OS can be Y2K compliant, the system calls are Y2K compliant, and the programming language can be Y2K compliant, but a silly programming error can decertify the whole system.

Why is the Mac Y2K compliant when other operating systems aren't? I think the answer has to do with the fact that there is no command line mode on the Mac. In many other systems, you can write a quick command line utility. Since the utility didn't take long to write, you don't feel it has to be tested thoroughly. On the Mac, however, you have to paint an entire window. Since that is harder to do, you spend more time with design issues, and spend more time in testing it.

BTW, Y2K compliance doesn't just affect computers. Banks will have to destroy millions of dollars worth of documents just because many are preprinted with "19__" on them. It may be time to think of ordering some new checks.

David Weintraub
Citibank

A big Mac Observer thanks to David, Gerben, and all the rest of the people who wrote in with their explanations!

Apple