Hello All,
I am writing a Scheduler (posted question regarding timers earlier) which must handle long delays: from 1s to several days. What would be the easiest way to add, lets say, 10.000 seconds to the current Calendar time?
Is there any library to help me with RTC_TimeTypeDef & RTC_DateTypeDef manipulation or do I have to handle this manually? I feel that manual date handling (and different day count in different months) is going to be time consuming and somewhat redundant.
Thanks, G.
Thanks guys.
Apologies for the cross post. Tried to remove the other one, but no such option.
I've tried to use time.h functions but without success:
struct tm ti; ti.tm_sec = 0; ti.tm_min = 0; ti.tm_hour = 0; ti.tm_mday = 1; ti.tm_mon = 0; ti.tm_year = 0; ti.tm_isdst = 0; time = mktime(&ti);
It gives me time = 7C558180 or 2085978496 or Thu, 07 Feb 2036 06:28:16 GMT and i expected to get a year 1900. Also, it modifies my "ti" fields to some specific values like "ti.tm_year = 88;"
This is not the behaviour I've expected. The same applies to localtime()/gmtime(). I get no values at all (debugger doesn't show anything) and I expected to get a "struct tm" filled with 0 values.
time_t input input = 1; output = localtime(&input);
Any clues what I'm doing wrong to get such a strange behaviour?
Thanks for the reply! Unfortunately, that didn't help.
And to make things worse, the source code for mktime() is not provided so I can't debug it easily...
Any other clues what should I look for?
You can download source code for a different mktime() and plug into your project in case you want to experiment based on the assumption that the error isn't in the mktime() call but in the actual code generation.
Ah, allright, figured it out.
Firstly, with the Options/Target/Use Micro Lib enabled, mktime() doesn't return -1 in cases it should. Secondly, I assumed, that if I enter ti.tm_year = 0 mktime() would return year 1970. Nope. It returns -1.
Apparently it only works with the "unix era dates - 1900", therefore:
ti.tm_year = YEAR - 1900; //where strictly YEAR >= 1970.
Note that before we got 64-bit machines, a number of libraries tried to make time_t an unsigned data type (i.e. forbidding times before 1970-01-01 00:00) just to make time_t capable of reaching further into the future. A 32-bit number is 4 billion seconds or about 136 years. So either +/- 68 years or 0..136 years if signed or unsigned.
Given a base time of 1970, we have already consumed over 43 of the 68 years until turn-over for a signed 32-bit time_t data type. It is quite possible for embedded projects to require support for dates further into the future than 2038. Lots of embedded systems are installed for 10 years or more.
In short - if you need to play with peoples birth dates etc, you shouldn't assume that the time_t data type will work well. Consider playing with julian dates or similar if you want to span large time ranges and still be able to compute the time difference.