Lsort 4.04 has been tested by London Computing and appears to be year 2000 compliant.  This means that the date fields defined in LSORT appear to sort properly after the year 2000.  Any dates stored in a character or numeric representation, not defined as a date field, may or may not sort properly depending on the definition of the data.  This is a function of the data and not of LSORT.  No effort is made to remediate any text, binary or packed fields that happen to contain dates.

LSORT 4.03 and earlier versions are not Y2K compliant.   A problem was discovered in LSORT 4.03 regarding sorting of the new date fields when the year ends in 00.  This problem was repaired in LSORT 4.04.

Until the Y2K issues became important, it was not necessary for LSORT to specifically deal with date fields. Release 4.02 of LSORT has added Y2K compliant date fields to helPproperly sort both old style and new style dates including a 2 character year field to handle dates that exceed the year 2000, MMDDYY, DDMMYY and YYMMDD fields that handle dates of the form mm/dd/yy, dd/mm/yy and yy/mm/dd respectively using the rule of 30, where yy fields <= 30 are assumed to start with 20, e.g. yy=30 means year 2030 and all other years are assumed to start with 19. In addition three types of date fields: MMDDYYYY, DDMMYYYY and YYYYMMDD are used to represent dates with 4 position years.

Although we believe that LSORT is indeed compliant, we do not warrant that it is Year 2000 compliant.

London Computing strongly suggests that you verify Year 2000 compliance in your environment before using LSORT in a production environment. 

If any Y2K problems are reported we will make every effor the fix the problem as quickly as possible.

LSORT 3.5a (OS/2 and DOS/Windows versions) have not been tested for Year 2000 compliance and must be considered to be non-compliant.