Y2K Windowing
  Issued: March 10, 1999;  Last Updated: N/A
Windowing is a mechanism that allows you to continue to use 2-digit years, mainly in input, so that the system converts the number to a properly prefixed year.  This is accomplished through the use of a "pivot", where years prior to a pivot point are assumed to be of the 21st century, and dates after the pivot are from the 20th century.  If your pivot is 30, then years before 30 are prefixed with "20", and years equal to or over 30 are prefixed with "19".  8/6/01 would be 8/16/2001; 6/21/84 would be 6/21/1984.  Windowing can be implemented in a number of ways:

  • A Basic Window creates a single threshold date for all dates:

    FUNCTION Y2K
    PARAMETER date_in

    IF YEAR(date_in) < 1980
       date_in = date_in + 100 years
    ENDIF

    RETURN date_in

    While simple in concept, this method has some obvious flaws.  First, it creates a fixed point of obsolescence, a new year where the Y2K problem will arise once again.  You have simply postponed the problem for awhile.  Second, a fixed window may not work for all fields.  For instance, birthdays may extend far into the past, but patent expiration dates may extend far into the future.  It is unlikely that a single pivot will fit all date occurrences in your application.

  • To alleviate this problem, you can create a Flexible Window, one that allows you to adjust the threshold date for each situation.

    FUNCTION Y2K
    PARAMETERS date_in,pivot_yr

    IF YEAR(date_in) < pivot_yr
       date_in = date_in + 100 years
    ENDIF

    RETURN date_in

    This allows you to set the best threshold for each occurrence.  For instance, birthdays, always in the past, may be converted using:

    birth_date = Y2K(birth_date,1920)

    Budget plans, mainly in the future, might be:

    plan_yr = Y2K(plan_yr,1990)

    This allows more flexibility, but problems still remain.  First, date ambiguity is heightened for the user, who would need to know the window for each date field in order to be able to interpret it correctly.  In the example above, "3/18/50" means 3/18/1950 for a birthday, but 3/18/2050 for a plan year.  Second, the problem of obsolescence still exists.  Sooner or later, you will reach a point where the established threshold for one of the date fields is no longer proper.

  • Obsolescence can be countered by using a Sliding Window, where you let the threshold date increase as the application ages:

    FUNCTION Y2K
    PARAMETERS date_in,slide_yrs

    pivot_yr = YEAR(SYSDATE()) - slide_yrs
    IF YEAR(date_in) < pivot_yr
       date_in = date_in + 100 years
    ENDIF

    RETURN date_in

    (Note that this requires that the system or underlying software have a proper current date, bringing into play the entire Y2K hierarchy.)

    As before, you can select the best threshold for each occurrence, and it will remain in effect indefinitely.  For instance, birthdays, always in the past, may be converted using:

    birth_date = Y2K(birth_date,90)

    In 2000, the threshold would be 1910, but in 2010, the threshold would be 1920.  Budget plans, mainly in the future, might be:

    plan_yr = Y2K(plan_yr,5)

    In 2000, the threshold would be 1995, but in 2010, the threshold would be 2005.

    So we've eliminated (or at least minimized) the problem of obsolescence, but again at a cost.  The ambiguity situation is worse than ever, with 2-digit years changing meaning every year.  Where a birthday of "5/14/10" means 5/14/1910 in 2000, it would mean 5/14/2010 in 2001.  Each field now has its own window and own interpretation, but that interpretation changes every year.