Run-time library

Nowhere. The run-tiem librarty is part of the toolchain and implicitely used. You don't need to know its funcitons nor do you need to program it.

However, some tweakign information (such as how to add your own pre-init code) is described in the linker manual. Which should be part of the toolchain installation (or search for it on the TI main site)

Sorry if my post was unclear. I am not looking to program the runtime library, I am looking for documentation as to what functions are included and any limitations they might have, or deviations from customary implementations. For instance, I had to dig through the source to find that "localtime" does not use time zone information, and in fact returns UTC not local time. I have not discovered why the day of the month is wrong, but I don't need it anyway.

So you're not looking for the runtime library, but rather for the C standard library. Well, I must admit that this difference is a bit fuzzy in the CCS documentation and there is no clear separation of the two.

The runtime library contains compiler/linker specific stuff like startup code, integer/float multiplication/division code etc.

The C standard library contains things you include with header files and use by function calls etc.

I'm sorry, but I don't know where you can find this information. If there is no separate document discussing it, I'd expect this kind of information as source code comments in the header files.

There are some hints regarding this in the  compiler users guide:

"The run-time library has minimal support for wide and multi-byte characters." and "The only supported locale is the C locale. That is, library behavior that is specified to vary by locale is hard-coded to the behavior of the C locale, and attempting to install a different locale by way of a call to setlocale() will return NULL."

It seems logical that if locale isn't supported, localtime won't support local time too (how do you set local timezone if there is no support for locale?), but of course one wouldn't expect it on first glance.

I am experiencing the same issue where the day of the month returned by using Code Composer is incorrect.

The unix date value 1388520000 is Tue, 31 Dec 2013 20:00:00 GMT, but the Code Composer localtime function returns that date value in the struct tm as Mon, 1 Jan 1 2014 20:00:00.  

The actual struct tm field values are:

tm_sec = 0
tm_min = 0
tm_hour = 20
tm_mday = 1
tm_mon = 0
tm_year = 44
tm_wday = 6
tm_yday = 0
tm_isdst = 0

I checked the TI library source code for localtime (v4.0.0) and mktime (v4.0.0).  I find it suspicious that TI localtime function initializes tm_mday to 1 before calling mktime to update the tm fields.  The other tm fields are initialized to zero.  I checked the gnu source code, presumably on which the TI libraries are based, and the gnu localtime function is completely different from the TI function.

Code Composer ver 5.1.1.00031
Compiler TI v4.0.0

Bruce,

i am not a compiler expert, but as far as i understand, you can find the RTS library source usually under e.g. for compiler v4.2.1 delivered with CCS v5.5:

<BASE_DIR>\ccsv5\tools\compiler\msp430_4.2.1\lib\rtssrc.zip. 

I am moving also this thread to the compiler forum to get in touch with the expert.

The answer is that TI does NOT use the UNIX epoch ( Jan 1, 1970 ) rather they use Jan 1, 1900. Like I said it wold be nice if they documented their implementation of the C standard library. As someone else pointed out it also defaults to US Central time zone.

Please see this related wiki article.

Thanks and regards,

-George

Thanks for all the replies.

I was not looking for an answer so maybe I should not have posted the problem here.  I encountered the day-of-by-one error in my software and investigated the issue.  When I discovered it was in the TI Standard Library, I wanted to let others know of the problem.

It's not an epoch problem.  It's not a timezone problem.  The problem is an improper value being set by localtime.  The localtime function is returning a day value that is one too much.  I know what is causing the problem and I have a workaround.  No further responses needed.

Thanks again to everyone for their quick replies.

Regards,

Bruce