Important Please note that although this document has been prepared for the benefit of Apple customers seeking information on Apple products and their compliance with Year 2000 issues, Apple assumes no liability for the failure of any of its products to be Year 2000 compliant, and cannot guarantee that the customers use of third-party software or hardware in conjunction with Apple products will be Year 2000 compliant. Summary The operating system independent Foundation APIs developed by NeXT and Apple, and used in WebObjects and OPENSTEP, have been specifically engineered to enable the development of Year 2000-compliant applications. This said, there are a number of issues of which developers need to be aware while building applications. It is possible to introduce Year 2000 issues into applications developed with these APIs in a number of ways, including: + Use of 2-digit years in date formats + Circumvention of the Foundation date and time APIs + Use of an underlying operating system which contains Year 2000-related defects Provided that developers are aware of these issues, applications developed with versions of WebObjects later than 3.0, and versions of OPENSTEP later than 4.0, should be able to effectively deal with date and time values thousands of years into the past and future. Foundation Issues While the Foundation APIs have been designed to minimize date-related issues, developers must still consider a number of factors when reviewing their code for Year 2000 compliance. Within the Foundation APIs themselves, there are ways in which developers can introduce 2-digit date dependencies into their applications. It is critical for developers to be aware that WebObjects and OPENSTEP applications depend on a platforms operating system to deliver the current date and time and some other pieces of information. Any implementation defects at that layer may also affect the functioning of the Foundation APIs. NSDates and the Year 2000 Dates are represented in the Foundation framework with NSDate and NSCalendarDate objects and NSTimeInterval values. An NSTimeInterval object is essentially a C-language double (NSTimeInterval can represent intervals of approximately 10,000 years with sub-millisecond accuracy). NSDates and NSCalendarDates store the date that they represent with an NSTimeInterval which represents the time delta in seconds from the Foundation reference date (00:00:00 Greenwich Mean Time January 1, 2000). This means that there is no special significance to the year 2000 for NSDate or NSCalendarDate objects or NSTimeInterval values. Since the internal time representation will transition across zero at the reference date--unlike some other schemes which set the epoch date to some point in the past--there will be a brief instant (on the order of microseconds in length) during which an NSDate object created to represent the current time will have an NSTimeInterval of zero. The length of this instant is dependent on the resolution of the system time provided by the particular operating system and platform on which an application is running. A NSTimeInterval of zero has no special significance to NSDate or NSCalendarDate, but applications that use the NSTimeInterval of a date object in division should protect against division by zero. As a practical matter, such applications are rare. It is likely that an application would have an NSTimeInterval that represents the delta between two arbitrary date objects. Even so, it is good practice to take appropriate caution when using such values. Risks in Parsing and Displaying Dates As with any communication between a program and the user, there can be miscommunication in displaying dates as well as in reading date values entered by the user. When a user types a date into a text field there may be a difference between the users intent and the programs interpretation. Similarly, a user may interpret a displayed date incorrectly. While an application cannot control the users interpretation per se, there are steps which developers may take to reduce the potential for ambiguity and even data corruption. Specifically the programmer and UI designer should avoid two-digit years and all uses of the %y date format specification. In general, developers should insure strict conformance to a fully specified input format and provide equally verbose formatting for the display and printing of dates. Date Formats (%y vs. %Y) Per POSIX and ANSI C (refer to section 7.12, ANSI/ISO 9899-1990 for ANSI C definitions), a two-digit year YY means 1900 + YY. The Foundation framework follows the lead of ANSI C on this point. When a user types 5/10/02 into a text field with a date formatter specified as %d/%m/%y a date of October 5, 1902 is created. The 2-digit date format (%y) makes it impossible for the user to type any entry that will yield the date October 5, 2002. For example, if the user types 5/10/2002 the formatter will truncate the last two digits and the date October 5, 1920 will be created. The date parsing routines parse a maximum of two digits for the %y format in order to support dates like 980409. In the same vein, a user has no way of knowing whether a displayed value of 28/10/33 refers to 1933 or 2033. Developers should use the %Y format specification (4 digit year field) to avoid this sort of problem Mach Operating System Issues Date and time values are stored in different formats in the Foundation framework and the Mach/BSD Unix core operating system. BSD UNIX keeps time as a signed 32-bit value to store seconds since January 1 00:00:00 Greenwich Mean Time 1970. This format can represent times until January 19 03:14:07 Greenwich Mean Time 2038. The /bin/date command There are a few isolated areas of the system where a two-digit year is expected. The first is the /bin/date command, which is used to set the date and time from the command line. The standard Unix version of the date command takes the following arguments: date [-n] [-u] [yymmddhhmm[.ss]] where yy is the year, mm is the month (01-12), dd is the day (01-31), hh is the hour (00-23), mm is the minute (00-59) and ss is the second (00-59). For OPENSTEP Release 4.1 and later, the /bin/date command was enhanced in a proprietary way to allow a three digit year field: date [-n] [-u] [[1]yymmddhhmm[.ss]] where the optional leading 1 implies a date in the 21st century; i.e., 10912251530 would be interpreted as December 25 3:30 PM Greenwich Mean Time 2009. If a two-digit year is entered, the value for the century is assumed to be 19 (i.e., 0912251530 would be interpreted as December 25 3:30 PM Greenwich Mean Time 1909). A version of the /bin/date command that uses a conventional 4 digit year format will be made available from Apple Computers Enterprise Software website at http://enterprise.apple.com/y2k/. This version will accept 4 digit years: date [-n] [-u] [[cc]yymmddhhmm[.ss]] where the optional cc parameter represents the century. If a two-digit year is entered, the value for the century is assumed to be 19. The tm structure The second area where a 20th-century bias is assumed is in the C language tm structure. This structure contains a field tm_year, which represents the number of years since 1900. Application code utilizing this structure will need to be able to deal with numbers greater than 99 in this field. For example, if the date is 01:00 February 11, 2000, the tm_year field will be 100. This means any application code that formats a date string by using the following printf statement will be incorrect after the year 2000: printf(%02d:%02d %d/%d/%d\n, tm.tm_hour,tm.tm_min,tm.tm_mon,tm.tm_mday,tm.tm_year); On the example date of 01:00 February 11, 2000, the above statement would produce the string 01:00 2/11/100. The RCS tools The third-party RCS tool set distributed with OPENSTEP 4.2 (and earlier) does not support dates after 1999. The latest freely available version of RCS has corrected this problem. If you wish to use RCS, you should obtain version 5.0 or later from http://www.gnu.org/. Foundation-based Applications on Other Operating Systems The same Foundation frameworks are available on all WebObjects and OPENSTEP implementations. This means that application developers writing to the OPENSTEP or WebObjects APIs do not have to worry about Year 2000 issues except as described in this document. It is the responsibility of the individual operating system vendor to provide Year 2000 support at the operating system level. Customers should contact their operating system vendor for information about Year 2000 issues at the operating system level. NEXTSTEP 3.3 NEXTSTEP 3.3 is not Year 2000 compliant. The Foundation framework is not an integral part of NEXTSTEP 3.3 (and is not available for earlier releases), and the APIs for NEXTSTEP 3.3 are not based on Foundation. In addition, the underlying Mach operating system has Year 2000 issues. Because NEXTSTEP 3.3 was released in 1994, is now obsolete, and is no longer a supported product, no Year 2000 fixes will be available for NEXTSTEP 3.3. Apple recommends that NEXTSTEP 3.3 customers contact their sales representative regarding possible upgrade options.