Compiler/TM4C1231H6PZ: gmtime() not have 2020.02.29 date

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",
      ptm->tm_mon+1,
      ptm->tm_mday,
      ptm->tm_year+1900,
      ptm->tm_hour,
      ptm->tm_min);

  puts("second test");
  rawtime = BASE_TIME+1;
  ptm = gmtime(&rawtime);

  printf("%2d-%2d-%4d %2d:%02d\n",
      ptm->tm_mon+1,
      ptm->tm_mday,
      ptm->tm_year+1900,
      ptm->tm_hour,
      ptm->tm_min);

  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,

-George

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

2020.03.01.JPG

2020.02.28