The following is FastIO Systems' complete statement on the Year 2000 compliance of the ClibPDF library. This applies to version 1.02 or later of ClibPDF distribution as available from our web server unmodified by any third party. This is for your information only, and is NOT a warranty of any kind.
To the best of our knowledge, the only uses of date in ClibPDF are through the standard C run-time library functions and data-types defined for their use [time(), ctime(), mktime(), etc]. On most current systems, these functions use a "long" (signed 32-bit) integer data type to maintain time as the number of seconds since a date in 1970. Therefore, ClibPDF functions are expected to operate correctly until year 2037 or as long as dates beyond year 2037 are not used during processing. If dates beyond year 2037 are used, the 32-bit integer (maximum positive integer is (2^31)-1) will roll over to a negative number (see below), and incorrect results and/or a program crash may occur.
The correctness of the results, of course, depends on the assumtion that the C or any other libraries to which ClibPDF is linked against are implemented correctly. It is your responsibility to verify that this is the case on the platform you have chosen to deploy ClibPDF applications. In addition, programmer(s) who utilize ClibPDF also must implement date and time functions correctly in her/their part of the program such that truncation of precision will not result. These are two of the possible factors that are beyond our control.
You are hereby warned that all applications that incorporate ClibPDF must be recompiled and re-linked with the compiler and C library for systems that maintains time using 64-bit integers well before year 2037. Any continued use of binary executables created on current systems will result in program mulfunctions after year 2037 or whenever dates beyond 2037 are used during processing. The use of such date may occur well before year 2037, depending on applications. The Year 2038 Problem is not unique to ClibPDF. Nearly all current applications and systems are expected to suffer from this problem.
Therefore, the year the overflow occurs is:
1970 + 68.05 = 2038.05.