c2000 cgt 15.x.y time.h changes

I don't see how that could possibly be.  For the TI time functions (which use Epoch 1900), both of those time_t values are on 1945-10-21.  Here is my program demonstrating this; you can run it under CCS.  If this does not answer your question, please post the code demonstrating that you get those values for that date.

#include <stdio.h>
#include <time.h>

int main()
{
    _tz.timezone = 0;

    time_t now_t = time(NULL);
    struct tm now_tm = *gmtime(&now_t);
    printf("now:  %lu\n", (unsigned long)now_t);
    printf("now:  %s\n", ctime(&now_t));

    struct tm then_tm = now_tm;
    then_tm.tm_year = 2015 - 1900;
    then_tm.tm_mon = 9; /* October */
    then_tm.tm_mday = 16; /* 16th */
    then_tm.tm_hour = 16;
    then_tm.tm_min = 29;
    then_tm.tm_sec = 0;
    time_t then_t = mktime(&then_tm);
    printf("then: %lu\n", (unsigned long)then_t);
    printf("then: %s\n", ctime(&then_t));

    time_t val1_t = 1445444940;
    printf("val1: %s\n", ctime(&val1_t));

    time_t val2_t = 1445423340;
    printf("val2: %s\n", ctime(&val2_t));
}

Hi Archaeologist, thanks for responding.

The range of the values I posted earlier were adjusted for 1970<->1900 epoch difference 2208988800.

1445012940 (1970 epoch start)

+2208988800 (1900 epoch start -> 1970 epoch start)

=3654001740

which is right and what 6.4.9 seems to have calculated correctly.

Here are some screenshots from a live debug session on an F28035.

CGT 6.4.9

CGT 15.12.1

The difference curiously seems to be 21600.  After looking at RTS source in mktime.c, 15.12.1 has

return result + (_tz.timezone - EPOCH_TZONE);

while 6.4.9 has only

return result;

After reviewing further, it seems there is an issue with the sign of _tz.timezone and perhaps with localtime vs gmtime.

By default, _tz.timezone = 21600, but shouldn't it be -21600 for CST (GMT - 6)?  Maybe I have the definition reversed?

Let's take an arbitrary date as an example,

Feb 22, 2016 18:50:31 GMT = 3665155831 (POSIX 1456167031 + 2208988800)

time_t u1,u2;
struct tm t1,t2;
_tz.timezone = 21600;
t1.tm_hour = 18;
t1.tm_min = 50;
t1.tm_sec = 31;
t1.tm_mon = 1;
t1.tm_mday = 22;
t1.tm_year = 116;
u1 = mktime(&t1);
t1=*localtime(&u1);
t2=*gmtime(&u1);
u2 = mktime(&t2);

_tz.timezone = 0;
u1 = mktime(&t1);
t1=*localtime(&u1);
t2=*gmtime(&u1);
u2 = mktime(&t2);

6.4.9

With _tz.timezone = 21600,

u1 = 3665155831 which is the correct NTP epoch timestamp (Jan 1, 1900 midnight GMT), and not the TI epoch timestamp (Jan 1, 1900 midnight CST).

t2 is ahead 6 hours of t1 and u2 = 3665177431.  I thought gmtime was supposed to create a time structure that was GMT, and localtime would have timezone offset applied.  Are gmtime and localtime are swapped?

With _tz.timezone = 0, u1 = u2 = 3665155831 as expected.

So it seems in 6.4.9, mktime does not care about timezone.  It produces NTP epoch timestamp and not the TI epoch timestamp.  Also, localtime doesn't apply _tz.timezone, while gmtime does (was expecting opposite behavior).

15.12.1

With _tz.timezone = 21600,

u1 = 3665155831 and t2 is ahead 6 hours of t1 and u2 = 3665177431 = u1 + _tz.timezone, same as in 6.4.9.

With _tz.timezone = 0,

u1 = u2 = 3665134231, which is is the TI epoch (NTP epoch - 21600) ... but now we are subtracting the offset??