Re: Y2K bugs in OpenLDAP (ITS#233)

[Kurt@OpenLDAP.org]

At 07:09 AM 7/21/99 GMT, kst@SDSC.EDU wrote:
>I've found some Y2K bugs in UMich LDAP 3.3; I'm in the process of
>trying to find out how to report them to someone who can actually
>do something about them.  (There hasn't been an update since 1996).

The project is defunct.  OpenLDAP has picked open source LDAP
(and is derived from U-Mich LDAP 3.3).

>While trying to track this down, I found the OpenLDAP web site,
>downloaded version 1.2.4 -- and found that it has the same problems.
>All the problems (well, all the ones I've found) involve a misuse of
>the tm_year member of a struct tm.  The tm_year member is defined as
>the number of years since 1900.  Some of the code in question assumes
>it's year % 100 -- and some of it doesn't even get that right.
>
>A quick summary:
>
>In clients/ud/print.c, the functions time2text and gtime assume an
>input format that uses a 2-digit year.  There is no windowing; the
>function will simply break after 1999.

The code is used with lastModifiedTime which doesn't have the
century.  The code should be updated to use modifyTimeStamp
instead, in which case the time parser needs to be updated.

>In contrib/whois++/util.c, the function convertTime has the same problem.

whois++ is contribware and currently without a maintainer.
It's the same basic problem as above.

>In libraries/libldap/tmplout.c, there's another implementation
>of time2text and gtime.  It appears that someone tried to fix
>this one, apparently unaware of the formerly identical functions
>in clients/ud/print.c.  This code attempts to be clever about the
>value of tm_year, assuming that if tm_year < 70 it needs to add
>2000, and that if tm_year >= 1900 it's the actual year.  My strong
>recommendation is to remove this code.  The tm_year value returned
>by any C runtime routine is year - 1900.  This is defined by the
>ANSI/ISO C language standard (not by POSIX as the comments indicate).
>It never makes sense to add 2000 to a tm_year value, or to assume that
>it might be a full 4-digit year.  For the year 1999, tm_year == 99;
>for 2000, tm_year == 100.  If a C runtime is so badly broken that it
>gets this wrong, it's not worth worrying about.

You are referring, I assume, to the YEAR_PEDANDIC macro.
You'll note that this macro is not used.

These routines likely should be exposed such that they
can be called by applications (such as ud).

>I'm afraid I don't really have the time to submit a fix for these
>problems, but I'll be glad to review the code once someone else has
>fixed and tested it.
>
>In the medium to long term, I urge you to use the ISO 8601 standard
>date format (YYYY-MM-DD) whenever a date needs to be represented
>as text.  See <http://www.cl.cam.ac.uk/~mgk25/iso-time.html> for
>more details.

The LDAP standards have specific requires for representing dates.
Unfortunately, not all date syntaxes require a century... though
we avoid using such syntaxes, we cannot stop users (and applications)
from using ill designed syntaxes.

>BTW, I've found that grepping for tm_year is an excellent way to
>flush out Y2K bugs in C source code.