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.

Compiler/TM4C1231H6PZ: gmtime() not have 2020.02.29 date

Part Number: TM4C1231H6PZ
Other Parts Discussed in Thread: MSP-EXP432E401Y, EK-TM4C1294XL, EK-TM4C123GXL

Tool/software: TI C/C++ Compiler

My Compiler version:TI v16.9.4.LTS

rawtime = UnixTimestamp;
ptm = *gmtime  (&rawtime);

When UnixTimestamp = 1582912799 the date is 2020.02.28 23:59:59

When UnixTimestamp = 1582912800 the date is 2020.03.01 00:00:00

Have new compiler version fix the issue?

  • Unfortunately, I am unable to reproduce that behavior.  Here is what I did.

    I created a new CCS project for the TI Launchpad MSP-EXP432E401Y.  It has this one source file ...

    #include <stdio.h>      /* puts, printf */
    #include <time.h>       /* time_t, struct tm, time, gmtime */
    #define OFFSET_HOURS 6L
    #define BASE_TIME 1582912799L + (OFFSET_HOURS * 60L * 60L)
    int main ()
      time_t rawtime;
      struct tm *ptm;
      puts("first test");
      rawtime = BASE_TIME;
      ptm = gmtime(&rawtime);
      printf("%2d-%2d-%4d %2d:%02d\n",
      puts("second test");
      rawtime = BASE_TIME+1;
      ptm = gmtime(&rawtime);
      printf("%2d-%2d-%4d %2d:%02d\n",
      return 0;

    I start with CCS project default options.  I increase the stack and heap each to 0x1000 words.  I added -D__TI_TIME_USES_64 so the epoch will be Jan 1, 1970 (which I presume you do as well).  When I run it, I get this output ...

    first test
     2-28-2020 23:59
    second test
     2-29-2020  0:00

    Please send me something similar which demonstrates the problem.

    Side note ... Here is the explanation regarding the OFFSET_HOURS hack.  I just experimented until I landed on the time_t values for the last second of Feb. 28 and 1 second later on Feb. 29.  I think it is different for me because I didn't change any of these values in the RTS source file tmzone.c.

    _DATA_ACCESS TZ _tz =
       -1,                      /* daylight */
       21600,                   /* timezone */
       "CST",                   /* tzname   */
       "DST",                   /* dstname  */

    But I didn't confirm that.

    Thanks and regards,


  • Hi George,
    Thank you for your reply.
    Is your environment MSP430? Is not the same compiler version?
    Follow is my debug screenshot.



  • George,

    I am able to reproduce the issue, but only when __TI_TIME_USES_64 is not defined. Attached is a test case that runs on the EK-TM4C123GXL launchpad. Let me know if you need one (or I can port it to the EK-TM4C1294XL Launchpad).


  • I understand what happened.  The TI compiler and RTS time functions are behaving as documented.  You made some incorrect assumptions.

    My answer will not make sense until after you understand the article Time and Clock RTS Functions.  Please focus on the part about the epoch.

    Avoid using raw time_t values like 1582912799 .  If you are forced to use them, then you have to know the epoch implied in those raw values, and that epoch must match the one used in the time related RTS functions.  In your case, the epoch does not match.  You assume the epoch is Jan 1, 1970.  But the epoch assumed in the RTS time functions is Jan 1, 1900.  You can change the epoch of the RTS time functions to Jan 1, 1970 by predefining the preprocessor symbol __TI_TIME_USES_64 .  The usual way to do that is to add the build option -D__TI_TIME_USES_64.  

    When the epoch is Jan 1, 1900, the year of the raw time value 1582912799 is 1950, which is not a leap year.  That is why there is no Feb 29.

    Note the definition of the structure field tm_year is the number of years since 1900.  This is the case without regard to the epoch.  It appears you assume tm_year is the number of years since 1970.

    Andy Deng said:
    Is your environment MSP430?

    No.  It is MSP432.  The CPU core of the system is an ARM Cortex-M4F.

    Andy Deng said:
    Is not the same compiler version?

    I used TI ARM compiler and RTS version number 16.9.4.LTS.

    Thanks and regards,


  • Thank you resolved my issue.