• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 114 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCSTUDIO: MSPM0L2228: <time.h> Run-Time Support Library

***
Prodigy 90 points

Part Number: CCSTUDIO

Based on the support library, I am using CIO and testing the time() function supported by <time.h> and my time is delayed by 2 hours. 

How can it be resolved? 

image.png

    // 1. Fetch Unix timestamp from host PC over JTAG CIO
    time(&raw_time);

    // 2. Convert to human-readable local time format structure
    pc_time = localtime(&raw_time);
if (pc_time != NULL) {
        printf("Host PC Time successfully captured!\n");
        printf("Date: %02d/%02d/%04d\n", pc_time->tm_mon + 1, pc_time->tm_mday, pc_time->tm_year + 1900);
        printf("Time: %02d:%02d:%02d\n", pc_time->tm_hour, pc_time->tm_min, pc_time->tm_sec);

    } else {
        printf("Failed to get time from host PC.\n");
    }
CORTEX_M0P: Host PC Time successfully captured!
CORTEX_M0P: Date: 06/11/2026
CORTEX_M0P: Time: 13:15:16

 

  • 0
    TI__Expert 6850 points

    Hi,

    Does using gmtime() return the correct value?

    Best Regards,
    Brian

  • 0 in reply to Brian Lee
    Prodigy 90 points

    Hey  , 

    I just tired gmtime() and both routines result same response.

  • 0 in reply to ***
    TI__Expert 6850 points

    Hi,

    The behavior you are seeing is expected. TI's CIO time() retrieves the host PC's time as a UTC Unix timestamp over JTAG — it does not capture your local timezone. On a bare-metal NoRTOS target, localtime() behaves identically to gmtime() because the device has no timezone database, so neither function applies any offset.

    To display local time, apply your UTC offset manually after the time() call:

    #define UTC_OFFSET_HOURS (2)   /* Set to your UTC offset, e.g. +2 for CEST */

time(&raw_time);
raw_time += UTC_OFFSET_HOURS * 3600;
pc_time = gmtime(&raw_time);

    Set UTC_OFFSET_HOURS to match your timezone (e.g. 2 for CEST, 1 for CET). Note that daylight saving transitions must be managed manually — the device has no automatic DST support, so you will need to update this value when your region changes between standard and summer time.

    Best Regards,
    Brian

  • 0 in reply to Brian Lee
    Prodigy 90 points

     , understood. Makes sense.
    Is what you mentioned documented anywhere? I want to make sure I am referencing any related documentation for other matters that will be helpful.

  • 0 in reply to ***
    TI__Expert 6850 points

    Hi,

    Additional documentation for these run-time functions can be found here in section 7.1.6: ARM Optimizing C/C++ Compiler v20.2.0.LTS User's Guide (Rev. W)

    To correct my previous reply: time() returns seconds since midnight CST (UTC-6), January 1, 1900 by default — not a
    UTC Unix timestamp. To use the UNIX 1970 UTC epoch instead, define __TI_TIME_USES_64 before including <time.h>.

    Best Regards,
    Brian

  • 0 in reply to Brian Lee
    Prodigy 90 points

     , I would like to make sure I understand this more and implementing correctly. Without the #define __TI_TIME_USES_64, should I expect the structure size to be 32-bits and when the #define is activated, it should be 64-bits?

    #include <stdio.h>

#ifndef __TI_TIME_USES_64
#define __TI_TIME_USES_64 1
#endif

#include <time.h>

.
.
.

void verify_time_configuration(void)
{
    printf("=== TI Time Configuration Test ===\n");

    // 1. Check size of time_t (Should be 8 bytes for 64-bit)
    printf("Size of time_t: %d bytes\n", (int)sizeof(time_t));

    if (sizeof(time_t) == 8)
    {
        printf("[SUCCESS] time_t is a 64-bit integer.\n");
    }
    else
    {
        printf("[WARNING] time_t is 32-bit. __TI_TIME_USES_64 is not active.\n");
    }

    // 2. Check the Epoch (Should result in 1970 standard)
    // 0 seconds from the 1970 epoch is Jan 1, 1970.
    // If it is using the legacy 1900 epoch, 0 seconds would print Jan 1, 1900.
    time_t test_epoch = 0;
    struct tm *epoch_time = gmtime(&test_epoch);

    if (epoch_time != NULL)
    {
        printf("Epoch baseline year: %d\n", epoch_time->tm_year + 1900);

        if (epoch_time->tm_year + 1900 == 1970)
        {
            printf("[SUCCESS] Using correct POSIX 1970 Epoch.\n");
        }
        else
        {
            printf("[WARNING] Using legacy %d Epoch.\n",
                   epoch_time->tm_year + 1900);
        }
    }
    else
    {
        printf("[ERROR] gmtime failed to process timestamp.\n");
    }

    printf("==================================\n");
}

    When I use the above code and run without #define and with #define activated, I seem to get the same results. Am I missing something fundamental?

    CORTEX_M0P: [SUCCESS] time_t is a 64-bit integer.

CORTEX_M0P: Epoch baseline year: 1970

CORTEX_M0P: [SUCCESS] Using correct POSIX 1970 Epoch.

CORTEX_M0P: ==================================

  • +1 in reply to ***
    TI__Expert 6850 points

    The behavior is the same with or without your #define because __TI_TIME_USES_64 is already defined to 1 by the compiler's own RTS header before your code is processed.

    machine/_types.h (part of the TI Clang RTS) defines __TI_TIME_USES_64 1 for ARM EABI targets. This header is pulled in transitively when anything includes <time.h>. So for any ARM Cortex-M target built with TI Clang, 64-bit time_t with the 1970 POSIX epoch is the default — no explicit #define is needed.

    You cannot get 32-bit time_t on this target without actively opting out. If you ever need the old behavior (32-bit, CST 1900 epoch), you would have to pass -D__TI_TIME_USES_64=0 as a compiler flag.

    Best Regards,
    Brian