contrib/ntp/NOTES.y2kfixes

   1 Name of the Application: xntp
   2
   3 Version Number:  4.0.91
   4
   5 Download Size: 4541953 bytes
   6
   7 Downloaded from: http://www.eecis.udel.edu/~ntp/
   8
   9 Operating Systems Supported: many
  10
  11 Operating Systems Tested: unix
  12
  13 Testing
  14
  15 Dates tested (CPU clock set)
  16
  17         1999-12-31
  18         2000-01-01
  19         2000-02-29
  20
  21         Critical fragments of code tested with other dates by special
  22         algorithms.
  23
  24 Hardware Platform: Sun Sparc
  25
  26 OS: Solaris 2.6
  27
  28 Compiler: gcc
  29
  30 Version: 2.8.1
  31
  32 Repairs:  9
  33
  34 No. of files Repaired: 13
  35
  36
  37 Compilation of Patches Required: yes
  38
  39 Results Description:
  40
  41 1)      Tested suspicious code.
  42
  43 2)      Repaired problem code and added documentation to ntp.h.
  44
  45 3)      Verified ntpd works on critical Y2K dates.
  46
  47
  48 Comments:
  49
  50 1)      Errors were found in improper use of tm_year within struct tm,
  51         calculations that did not support year 2000 as a leap year
  52         (it truly is, despite any unchanged comments remaining in
  53         the NTP source), and some incorrect date calculations, while
  54         not traditional Y2K errors, would break in the year 2000.
  55
  56 2)      include/ntpd.h
  57         Added some definitions and documentation about the right way
  58         of doing things.  Definitions used by most, if not all, of
  59         the Y2K repairs.
  60
  61 Cautions:
  62
  63 1)      Some of the Y2K repairs were to reference clock drivers that
  64         we did not have the local hardware to test.  While I believe
  65         the changes are sound, they really need to be tested.
  66         This includes:
  67
  68                 refclock_arc.c
  69                 refclock_heath.c
  70                 refclock_hpgps.c
  71
  72         Also, parseutil/dcfd.c is another hardware dependent module that
  73         was repaired without live testing.
  74
  75 Non-Y2K Problems Observed:
  76
  77 1)      Inconsistent casts of variables containing time values may
  78         make expansion to 64 bit integer values in a portable manner
  79         difficult.
  80
  81 2)      libntp/caltontp.c:
  82         Has logic I believe will fail starting in year 2100 or so.
  83         Left unchanged/untested as it works well beyond basic NTP 2036
  84         limit checked by check_y2k.c.
  85         If NTP is implemented on 64-bit machines, this should be fixed
  86
  87 3)      ntpd/refclock_acts.c:
  88         ACTS time format has changed somewhat since the code was written.
  89         In particular the '*' '#' character switch no longer occurs...
  90         only '*' is typed.
  91
  92       NOTE: Author (falsely) stated Y2K is NOT a leap year when it
  93       really is.
  94
  95       TRUTH: ACTS will go beyond Y2K: it uses FourDigitYear % 100 values
  96       for year so year 2000 will revert to "00".
  97
  98
  99 4)     ntpd/refclock_oncore.c
 100        Some very strange logic in manipulating year values:
 101        1122         instance->pp->year = buf[6]*256+buf[7];
 102        Multiply by 256????
 103
 104     Response from PHK:
 105        The entire protocol is binary, the year is a 16 bit quantity
 106        which according to the manual can have the range 1998-2018.
 107