Weird results in DateTime class

In the DateTime class the time is stored as an 'unsigned long'. As long as you are working with a current date this value will be a positive long number.

In DateTime.cpp (line 73) there is a small error :

time_t long epoch=*timep;

The keyword 'long' leads to errors. If you are using a future date and this value becomes 'negative' the routine 'localTime' returns funny results. For example you receive 233 minutes and 198 seconds.

Simply delete the 'long' and everything works.

I don't know how to address the developer of this very nice library but I hope he will see my little notice and will correct the source for the next release.

Thanks to all who do a great job in keep running the Arduino project.

k-015

quite right k-015. the 'long' in that expression should not be there. I will upload a new version with the fix when I get a chance.

@mem:
Thanx for the quick response.

Thanks for the feedback. BTW, I am looking for ideas for simple example sketchs for the library. Any suggestions?

I think that the existing sample sketch is enough for using this class. On the other side i used the makeTime method and found that there is always one month too much in counting. The routine should count only the completed months but it adds the running month as well.

I changed this part like this

// add days for this year (only completed months)
if (month > 1) { // if january there are no completed months
for (i=0; i<(month-1); i++) {
if (i==1 && LEAP_YEAR(year)) {
seconds+= 606024L29;
} else {
seconds+= 60
6024LmonthDays*;*

  • }*
  • }*
  • }*
    As i have no assembler output in my IDE I'm always not sure when the condition in the for-loop is used so i made an extra if-request to make sure that if we are in january no time is added.
    The class is very helpful and i think there are a lot of applications that can use it.
    BTW i have a little problem:
    I'm taking the time from a NTP server but i have no idea how i can find out (with only a few commands) if i have to change to summer or winter time. That would be a nice feature if the DateTime class could automatically change to summer time.
    Bye k-015

Hi K-015
January is month 0 so the loop in the published code will not execute if makeTime is called with January. Were you passing a value of 1 for January?

Adding functionality to hold the next transition date for summer time and winter time would be nice, but logic would also be needed to cope with cases where the clock was set on local time that already had the offset. Also each call to get the local time would need to check for a transition from summer time to winter time. Suggestions for an efficient way of handling both of these would be welcome.

I passed the parameters as usual. For the date 05, June 2009 i passed 05, 06, 09. And after that i was wondering why my routine was always 30 days in advance. For me January is the first and December is the 12th month of the year. That is why i made the little changes in the makeTime routine.

But it's ok. The discussion of beginning with 0 or 1 is as old as the IT world and it is not worth to start a discussion about that. When you leave that piece of software as it is right now I can live with that fact. Absolutely no problem.

Bye k-015