Two related Y2038 issues in property lists

[sctol]

I noticed a couple of issues with the definition of plist_new_date(int32_t secs, int32_t usecs) that will manifest on January 18, 2038.

secs is defined as the number of seconds since Jan 1, 1970. usecs is in microseconds. Both are passed in as signed 32-bit values. secs will overflow the sign bit, going negative near the end of January 18, 2038 UTC, making an internal Plist date value representation also go negative.

A second problem occurs with how the date is internally stored in the Plist node structure. This is defined as an IEEE-754 double precision floating point value with 52 bits in the mantissa, with the least significant bit containing any roundoff error. The double is calculated with the following formula:

double value = (double) secs + (double) usecs/1000000;

It takes 20 bits from the mantissa to represent usecs, leaving 32 bits for seconds and roundoff. As secs increases above 31 bits, the double value begins carrying more roundoff error, resulting in less accurate microsecond information for any double precision floating point math operations involving Plist dates.

Apple Objective-C and GNUStep may have this exact same issue in their implementations of Plists.

[AiXanadu]

I don't think they will consider that there will be 32-bit in 2038.