Issue with using ctime to advance a given date to next calendar date

Question

I wrote the following piece of code to advance the input date to the following calendar date. This works well when tested in a dummy source file compiled with g++ 4.1.2

However, when running the following code from within my firm's simulator(intricate details of which are unavailable to me at this point), it breaks on 20021027; i.e. for dates other than 20021027, it works as intended but for 20021027, it returns 20021027 itself.

Please advise as to what could be going wrong?

int nextday(const int &date, int n=1)
{
    struct tm curr_time;

    int yyyy = curr_time.tm_year = date/10000-1900;
    int mm = curr_time.tm_mon=(date/100)%100-1;
    int dd = curr_time.tm_mday=date%100;
    curr_time.tm_min=0;
    curr_time.tm_sec=0;
    curr_time.tm_hour=0;

    time_t next = mktime(&curr_time) + 24*60*60*n;
    struct tm new_time;
    localtime_r(&next,&new_time);
    yyyy = 1900 + new_time.tm_year;
    mm = 1 + new_time.tm_mon;
    dd = new_time.tm_mday;
    return (10000*yyyy+100*mm+dd);
}

Answer 1

I don't see why that one date would cause problems, but I don't understand why you're doing things the hard way. Just add one to the tm_mday field before calling mktime, then extract the corrected values from the struct tm you passed into mktime. (There's a reason why the pointer into mktime points to non-const.) Something like:

int
nextday( int date, int n = 1 )
{
    tm broken_down;
    broken_down.tm_year = date / 10000 - 1900;
    broken_down.tm_mon = (date / 100) % 100 - 1;
    broken_down.tm_mday = date % 100 + n;
    broken_down.tm_hour = 12;  // avoid issues with summer time, etc.
    broken_down.tm_min = 0;
    broken_down.tm_sec = 0;
    mktime( &broken_down );
    return (broken_down.tm_year + 1900) * 10000
        +  (broken_down.tm_mon + 1) * 100
        +  broken_down.tm_mday;
}

(You might want to add some sanity checks, i.e. verify that the int passed in really does represent a date in the expected format, and that n is in some reasonable range. Or if you can influence the decision, use some standard date format, so you don't have to.)

Anyway, I'd suspect some problem in the simulator, especially if it works with the same value locally.