A new Y2K bug!

Bug reports, work arounds and fixes

Moderators: arango, robertson

Post Reply
Message
Author
User avatar
m.hadfield
Posts: 520
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

A new Y2K bug!

#1 Post by m.hadfield » Mon May 01, 2017 11:00 pm

I think I've found a Y2K leap year bug in the new string-based date-time output.

I have a simulation that runs from mid-1999 to mid-2000. Below are some excerpts from the log file's time-step output.

Shortly after 2000-02-28 12:30, the date string switches from 2000-02-28 (which is correct) to 1999-03-**:

Code: Select all

    282840 2000-02-28 12:30:-0.00  7.232136E-03  9.595376E+03  9.595384E+03  6.127136E+13
                     (268,100,11)  3.108790E-02  1.518986E-02  3.171568E-01  2.214117E+00
    282841 2000-02-28 12:31:15.00  7.248462E-03  9.595342E+03  9.595349E+03  6.127158E+13
                     (268,100,11)  3.125993E-02  1.464380E-02  3.242527E-01  2.211739E+00
    282842 1999-03-** 12:32:30.00  7.264872E-03  9.595307E+03  9.595314E+03  6.127180E+13
                     (268,100,11)  3.140089E-02  1.412618E-02  3.304424E-01  2.209156E+00
    282843 1999-03-** 12:33:45.00  7.281359E-03  9.595272E+03  9.595279E+03  6.127202E+13
                     (268,100,11)  3.151144E-02  1.363791E-02  3.357258E-01  2.206374E+00
Approximately 11.5 hours later it switches to displaying 1999-03-00:

Code: Select all

    283390 1999-03-** 23:57:30.00  6.609699E-03  9.595895E+03  9.595902E+03  6.126093E+13
                     (225,230,13)  1.395998E-03  3.059932E-03  3.169761E-01  1.516077E+00
    283391 1999-03-** 23:58:45.00  6.614548E-03  9.595888E+03  9.595895E+03  6.126107E+13
                     (225,230,13)  1.458596E-03  3.071249E-03  3.169640E-01  1.530639E+00
    283392 1999-03-00 00:00:-0.00  6.619608E-03  9.595881E+03  9.595888E+03  6.126121E+13
                     (225,230,13)  1.520579E-03  3.081869E-03  3.169531E-01  1.544468E+00
    283393 1999-03-00 00:01:15.00  6.624877E-03  9.595874E+03  9.595880E+03  6.126135E+13
                     (225,230,13)  1.582087E-03  3.091852E-03  3.169484E-01  1.557555E+00
And 24 hours later it switches to displaying 2000-03-01:

Code: Select all

    284542 1999-03-00 23:57:30.00  6.650543E-03  9.595797E+03  9.595804E+03  6.125572E+13
                     (225,230,13)  3.434859E-03  3.093516E-03  2.980265E-01  1.128973E+00
    284543 1999-03-00 23:58:45.00  6.647596E-03  9.595823E+03  9.595830E+03  6.125571E+13
                     (225,230,13)  3.363811E-03  3.093947E-03  2.981194E-01  1.129141E+00
    284544 2000-03-01 00:00:-0.00  6.644884E-03  9.595848E+03  9.595855E+03  6.125571E+13
                     (225,230,13)  3.295401E-03  3.093909E-03  2.982116E-01  1.129228E+00
    284545 2000-03-01 00:01:15.00  6.642410E-03  9.595873E+03  9.595879E+03  6.125570E+13
                     (225,230,13)  3.229865E-03  3.093444E-03  2.983071E-01  1.129230E+00
IIRC 2000 was a leap year (though 1600 was not and 2400 will not be) so what should be 2000-02-29 is being displayed as 1999-03-00 and the second half of 2000-02-28 is being displayed as 1999-03-**.

I haven't run the model through any other February-March transitions

User avatar
arango
Site Admin
Posts: 1100
Joined: Wed Feb 26, 2003 4:41 pm
Location: IMCS, Rutgers University
Contact:

Re: A new Y2K bug!

#2 Post by arango » Thu May 25, 2017 11:04 pm

Weird. What calendar are you using?

The behavior of your time reporting indicates to me that you are using the Proleptic Gregorian Calendar (time_ref=0 or time_ref>0). The datenum and datevec routines in ROMS starts in in March 1, 0000 to facilitate the management of leap years:

Code: Select all

      MyMonth=MOD(month+9, 12)                    ! Mar=0, ..., Feb=11
      MyYear=year-INT(0.1_r8*REAL(MyMonth,r8))    ! if Jan or Feb,
!                                                   substract 1
      DaysPerYear=INT(365.0_r8*REAL(MyYear,r8))+                        &
     &            INT(0.25_r8*REAL(MyYear,r8))-                         &
     &            INT(0.01_r8*REAL(MyYear,r8))+                         &
     &            INT(0.0025_r8*REAL(MyYear,r8))
      MyDay=DaysPerYear+                                                &
     &      INT(0.1_r8*(REAL(MyMonth,r8)*306.0_r8 + 5.0_r8))+           &
     &      (day - 1)
Numerically, the number of days in a year are determined on March 1 each year.

I did checked the Y2K problem using the Matlab version of ROMS dateclock.F routines: daynum.m and dayvec.m.

If I try your values, I get the correct values:
  • dayvec(daynum(2000,2,28,12,30,0))

    Code: Select all

    ans = 
    
           daynum: 730483.520833333
        leap_year: 'true'
             yday: 59
             year: 2000
            month: 2
              day: 28
             hour: 12
          minutes: 30
          seconds: 0
           string: '2000-02-28 12:30:0.00'
  • dayvec(daynum(2000,2,28,12,31,15))

    Code: Select all

    ans = 
    
           daynum: 730483.521701389
        leap_year: 'true'
             yday: 59
             year: 2000
            month: 2
              day: 28
             hour: 12
          minutes: 31
          seconds: 15
           string: '2000-02-28 12:31:15.00'
  • dayvec(daynum(2000,2,28,12,32,30))

    Code: Select all

    ans = 
    
           daynum: 730483.522569444
        leap_year: 'true'
             yday: 59
             year: 2000
            month: 2
              day: 28
             hour: 12
          minutes: 32
          seconds: 30
           string: '2000-02-28 12:32:30.00'
  • dayvec(daynum(2000,2,28,12,33,45))

    Code: Select all

    ans = 
    
           daynum: 730483.5234375
        leap_year: 'true'
             yday: 59
             year: 2000
            month: 2
              day: 28
             hour: 12
          minutes: 33
          seconds: 45
           string: '2000-02-28 12:33:45.00' 
  • dayvec(daynum(2000,2,28,23,57,30))

    Code: Select all

    ans = 
    
           daynum: 730483.998263889
        leap_year: 'true'
             yday: 59
             year: 2000
            month: 2
              day: 28
             hour: 23
          minutes: 57
          seconds: 30
           string: '2000-02-28 23:57:30.00'
  • dayvec(daynum(2000,2,28,23,58,45))

    Code: Select all

    ans = 
    
           daynum: 730483.999131944
        leap_year: 'true'
             yday: 59
             year: 2000
            month: 2
              day: 28
             hour: 23
          minutes: 58
          seconds: 45
           string: '2000-02-28 23:58:45.00'
  • dayvec(daynum(2000,2,29,0,0,0))

    Code: Select all

    ans = 
    
           daynum: 730484
        leap_year: 'true'
             yday: 60
             year: 2000
            month: 2
              day: 29
             hour: 0
          minutes: 0
          seconds: 0
           string: '2000-02-29 00:00:0.00'
  • dayvec(daynum(2000,3,1,0,0,0))

    Code: Select all

    ans = 
    
           daynum: 730485
        leap_year: 'true'
             yday: 61
             year: 2000
            month: 3
              day: 1
             hour: 0
          minutes: 0
          seconds: 0
           string: '2000-03-01 00:00:0.00'
Notice that I getting year 2000 as a leap year. I don't know what is going on :shock: I did noticed that you get negative zeros in the string. I haven't noticed those in my runs. I modified a little dateclock.F in ROMS to guarantee that seconds are positive by taking the absolute value:

Code: Select all

 
       seconds=DayFraction*86400.0_r8
       CT=3.0_r8*EPSILON(seconds)             ! comparison tolerance
       seconds=ROUND(seconds, CT)             ! tolerant round function    
!
       hour=INT(seconds/3600.0_r8)
       seconds=ABS(seconds-REAL(hour*3600,r8))
       minutes=INT(seconds/60.0_r8)
       seconds=ABS(seconds-REAL(minutes*60,r8))
The negative values maybe due to round-off when conputing minutes.

I updated the Matlab scripts to be exacty how ROMS compute the date clock. See the following trac tickets for :arrow: ROMS and :arrow: matlab repositories.

Please update ROMS and Matlab repositories. I will keep looking. I will need to have a test to see if I can reproduce your results so I can look in the debugger.

User avatar
arango
Site Admin
Posts: 1100
Joined: Wed Feb 26, 2003 4:41 pm
Location: IMCS, Rutgers University
Contact:

Re: A new Y2K bug!

#3 Post by arango » Fri May 26, 2017 8:17 pm

Fixed the bug. It was not a Y2K bug. I coded datevec incorrectly in module dateclock.F. I was able to reproduce your problem with a simple test. Now, I get:

Code: Select all

         1 2000-02-28 00:02:30.00  9.193018E-09  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,32,30)  1.799562E-05  8.159871E-10  0.000000E+00  4.667957E-03
         2 2000-02-28 00:05:00.00  3.669912E-08  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,30)  8.922418E-08  6.310334E-08  8.579133E-05  9.333864E-03
         3 2000-02-28 00:07:30.00  8.240137E-08  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,30)  1.296542E-07  1.724637E-07  1.205067E-04  1.399454E-02
         4 2000-02-28 00:10:00.00  1.462817E-07  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,30)  1.667237E-07  3.255255E-07  9.203260E-05  1.865130E-02
         5 2000-02-28 00:12:30.00  2.282939E-07  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  3.140349E-07  5.122608E-06  9.876424E-05  2.330335E-02
         6 2000-02-28 00:15:00.00  3.283527E-07  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  4.504366E-07  6.037931E-06  1.197387E-04  2.795021E-02
         7 2000-02-28 00:17:30.00  4.463811E-07  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  6.084865E-07  6.901414E-06  1.418026E-04  3.259130E-02
         8 2000-02-28 00:20:00.00  5.823121E-07  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  7.867765E-07  7.706325E-06  1.646507E-04  3.722601E-02
         9 2000-02-28 00:22:30.00  7.360571E-07  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  9.840808E-07  8.473146E-06  1.872866E-04  4.185361E-02
        10 2000-02-28 00:25:00.00  9.075024E-07  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  1.199968E-06  9.241814E-06  2.090232E-04  4.647330E-02
        11 2000-02-28 00:27:30.00  1.096525E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  1.434981E-06  1.004841E-05  2.299361E-04  5.108418E-02
        12 2000-02-28 00:30:00.00  1.288030E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  1.690266E-06  1.090592E-05  2.506269E-04  5.449963E-02
        13 2000-02-28 00:32:30.00  1.462197E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  1.966928E-06  1.180089E-05  2.717118E-04  5.675077E-02
        14 2000-02-28 00:35:00.00  1.632312E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  2.265510E-06  1.270431E-05  2.934621E-04  5.892863E-02
        15 2000-02-28 00:37:30.00  1.797956E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  2.585816E-06  1.358751E-05  3.157401E-04  6.104299E-02
Please check the following :arrow: trac ticket for details. Thank you for reporting this bug.

Post Reply