Kermit software is not, for the most part, date dependent. It makes connections, performs terminal emulation (in those versions that include this feature), transfers files, translates character sets, and, in most cases, executes scripts regardless of the date.
"Year 2000 compliance" depends on the Kermit program and the underlying platform. If the operating system, file system, BIOS, hardware, and/or other critical component is not ready for the year 2000, then most likely Kermit isn't either, since it relies on the underlying OS and hardware for date / time service.
The primary relevance of this question to Kermit software is whether post-millenium file dates are recognized, transmitted, received, and reproduced correctly during the file transfer process. This consideration, in turn, applies only to those Kermit versions that implement the optional "Attribute Packet" feature. These include C-Kermit, Kermit 95, MS-DOS Kermit, Kermit-370, and PDP-11 Kermit, all of which are coded to write and read 4-digit years in all protocol messages. (Note that these programs also include a command to disable file-date processing altogether, in the event that it does not work as intended.)
If post-millenium dates are not processed correctly, file transfer will still take place, but the creation or modification date of the received file might be incorrect. An exception would be if the "file collision update" feature is being used to prevent unnecessary transfer of files that have not changed since the last time a transfer took place; in this case, a file might be transferred unnecessarily, or it might not be transferred when it should have been. Correct operation of the update feature depends on both Kermit programs having the correct date and time.
Another exception would be when using the /BEFORE: or /AFTER: file-selection switches during file transfer. If dates are not processed correctly, files could be skipped that should have been sent, or vice versa.
If an incoming file is stored with the wrong date, for example with a year of 1900 rather than 2000, this might affect backup, archival, and cleanup procedures, perhaps resulting in unwanted file deletion. For example (in VMS):
$ delete/before="-90-" *.*;* $ dir/since=1-jan-2000 $ purge/before=login *.*
Of secondary importance are the time stamps in the transaction and/or debug logs, and the date-related script programming constructs, such as \v(date), \v(ndate), \v(day), \v(nday), and perhaps also the time-related ones, \v(time) and \v(ntime), insofar as they might be affected by the date. Note: the aforementioned script programming constructs are available only in C-Kermit, Kermit 95, and MS-DOS Kermit. The \v(ndate) is a numeric-format date of the form yyyymmdd, suitable for comparison and sorting: e.g. 19970208 or 20011231. If the underlying operating system returns the correct date information, these variables will have the proper values. If not, then scripts that make decisions based on these variables might not operate correctly, but then neither will any other date-related software on your computer.
Here is the current situation for the most popular Kermit software products. The minimum version known to be Year-2000 compliant is shown. We make no claims whatsoever about the underlying operating systems or file systems. The situation with Kermit programs not listed here is at present unknown.