This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Year 2036 Bug in sl_DevGet of Time of Day/Date - Possible to get just SNTP seconds?

Other Parts Discussed in Thread: CC3200

The sl_DevGet of the time set on the network processor fails with the year 2036 bug.  Granted it is 20 years away but I don't like inserting known future failures into products.

http://en.wikipedia.org/wiki/Network_Time_Protocol#Timestamps

Is it possible to simply read back the 32bit unsigned SNTP time stored on the network processor instead of relying upon the problematic network processor code to translate it into year/month/day hr:min:sec?

To reproduce the error you can use this code:

    UART_PRINT("Time Code Test\r\n");
    // Check for expected year 2036 sntp time problem.
    dateTime_g.sl_tm_year = 2035;
    dateTime_g.sl_tm_mon  = 1;
    dateTime_g.sl_tm_day  = 1;
    dateTime_g.sl_tm_hour = 13;
    dateTime_g.sl_tm_min  = 55;
    dateTime_g.sl_tm_sec  = 23;
    //
    xSize=sizeof(SlDateTime_t);
    xConfig=SL_DEVICE_GENERAL_CONFIGURATION_DATE_TIME;
    //
    sl_DevSet(SL_DEVICE_GENERAL_CONFIGURATION,SL_DEVICE_GENERAL_CONFIGURATION_DATE_TIME,sizeof(SlDateTime_t),(unsigned char *) (&dateTime_g));
    sl_DevGet(SL_DEVICE_GENERAL_CONFIGURATION,&xConfig,&xSize,(unsigned char *) (&dateTime2_g));
    UART_PRINT("%d-->%d/%02d/%02d %02d:%02d:%02d\r\n",dateTime_g.sl_tm_year, dateTime2_g.sl_tm_year,dateTime2_g.sl_tm_mon,dateTime2_g.sl_tm_day,dateTime2_g.sl_tm_hour,dateTime2_g.sl_tm_min,dateTime2_g.sl_tm_sec);
    //
    dateTime_g.sl_tm_year = 2037;
    sl_DevSet(SL_DEVICE_GENERAL_CONFIGURATION,SL_DEVICE_GENERAL_CONFIGURATION_DATE_TIME,sizeof(SlDateTime_t),(unsigned char *) (&dateTime_g));
    sl_DevGet(SL_DEVICE_GENERAL_CONFIGURATION,&xConfig,&xSize,(unsigned char *) (&dateTime2_g));
    UART_PRINT("%d-->%d/%02d/%02d %02d:%02d:%02d\r\n",dateTime_g.sl_tm_year, dateTime2_g.sl_tm_year,dateTime2_g.sl_tm_mon,dateTime2_g.sl_tm_day,dateTime2_g.sl_tm_hour,dateTime2_g.sl_tm_min,dateTime2_g.sl_tm_sec);
    //
    dateTime_g.sl_tm_year = 2040;
    sl_DevSet(SL_DEVICE_GENERAL_CONFIGURATION,SL_DEVICE_GENERAL_CONFIGURATION_DATE_TIME,sizeof(SlDateTime_t),(unsigned char *) (&dateTime_g));
    sl_DevGet(SL_DEVICE_GENERAL_CONFIGURATION,&xConfig,&xSize,(unsigned char *) (&dateTime2_g));
    UART_PRINT("%d-->%d/%02d/%02d %02d:%02d:%02d\r\n",dateTime_g.sl_tm_year, dateTime2_g.sl_tm_year,dateTime2_g.sl_tm_mon,dateTime2_g.sl_tm_day,dateTime2_g.sl_tm_hour,dateTime2_g.sl_tm_min,dateTime2_g.sl_tm_sec);
    //
    dateTime_g.sl_tm_year = 2050;
    sl_DevSet(SL_DEVICE_GENERAL_CONFIGURATION,SL_DEVICE_GENERAL_CONFIGURATION_DATE_TIME,sizeof(SlDateTime_t),(unsigned char *) (&dateTime_g));
    sl_DevGet(SL_DEVICE_GENERAL_CONFIGURATION,&xConfig,&xSize,(unsigned char *) (&dateTime2_g));
    UART_PRINT("%d-->%d/%02d/%02d %02d:%02d:%02d\r\n",dateTime_g.sl_tm_year, dateTime2_g.sl_tm_year,dateTime2_g.sl_tm_mon,dateTime2_g.sl_tm_day,dateTime2_g.sl_tm_hour,dateTime2_g.sl_tm_min,dateTime2_g.sl_tm_sec);
    //
    dateTime_g.sl_tm_year = 2015;
    sl_DevSet(SL_DEVICE_GENERAL_CONFIGURATION,SL_DEVICE_GENERAL_CONFIGURATION_DATE_TIME,sizeof(SlDateTime_t),(unsigned char *) (&dateTime_g));
    sl_DevGet(SL_DEVICE_GENERAL_CONFIGURATION,&xConfig,&xSize,(unsigned char *) (&dateTime2_g));
    UART_PRINT("%d-->%d/%02d/%02d %02d:%02d:%02d\r\n",dateTime_g.sl_tm_year, dateTime2_g.sl_tm_year,dateTime2_g.sl_tm_mon,dateTime2_g.sl_tm_day,dateTime2_g.sl_tm_hour,dateTime2_g.sl_tm_min,dateTime2_g.sl_tm_sec);

Which will produce the following output:

Time Code Test
2035-->2035/01/01 13:55:23
2037-->1900/11/26 07:27:07
2040-->1903/11/26 07:27:07
2050-->1913/11/26 07:27:07
2015-->2015/01/01 13:55:23

  • Jason,

    Thanks for pointing it out - I'll take this up internally and see what we can do to work around this problem. Shall keep you posted.

    -Praneet

  • TI,

    Please explain the decision to not address this bug.  According to the ...1.1 service pack release notes:

    ID MCS00131563
    Title Host:  Set/Get time is limited up to year 2038
    Description:  Due to a bug in time.h library that is limited to signed 32-bit integer, and this number
    is interpreted as the number of seconds since 00:00:00 UTC on 1 January 1970
    Impact:  Low impact – Certifications that are bounded by date will expire after year 2038
    Workaround:  N/A
    Fix Expected:  Not expected

    Note that the problem is not limited to certifications but also impacts those that use the NWP time/date to maintain time over LPDS.

    I would guess it was in fact that TI used a epoch of 1900 on the NWP instead of 1970 that caused the problem.  Note that if you add 2**32 secs/60/60/24/365 (approx 136 years) to 1970 you end up in year 2106 not 2036!!  Perhaps the person assigned to work on this problem should learn how to use a calculator (and perhaps gain some respect for those that wrote the time code that they blame for their problem).

    I suspect that many of your customers are unaware of this 20 year maximum lifespan of products developed with the cc3200.

  • Jasan,

    I'd need more details on the issue that you have pointed out w/ LPDS to help further.

    And to answer the other part of your question, the bug description clearly mentions that it is a signed 32-bit integer - Meaning only 31 bit for data and left most bit for sign. Now, 2 ^ 31 secs/60/60/24/365 is ~68years, which when added to 1970 is 2038.

    -Praneet

     

  • Closing this thread - Let me know if you need additional information on this. I suggest you open a new thread and give references of the current one for us to tract it better.

    -Praneet

  • I think one solution is move time base from 1970 to 2000, you have 30 more years to spare; and another one is convert 32-bit to 64-bit time.