regarding the behaviour of gmtime() Linux system function

[aryan1]

Hi All,

Following C++ function is expected to add 5 minutes to a certain date and time in "Broken-down time" format, and output the new date and time in the same format again:

void incrementDateAndTime()
{
    struct tm timeinfo;
    int minuteToAdd = 5;

    timeinfo.tm_year = 110;//actual year is 110 + 1900 = 2010
    timeinfo.tm_mon = 3;//actual month is 3 + 1 = 4
    timeinfo.tm_mday = 2;
    timeinfo.tm_hour = 10;
    timeinfo.tm_min = 55;

    time_t rawtime = mktime ( &timeinfo );

    rawtime += minuteToAdd*60;//add 300 seconds to Coordinated Universal Time (UTC)

    //point A

    struct tm* timeinfoNew = gmtime ( &rawtime );

    year  = timeinfoNew->tm_year  + 1900;
    month = timeinfoNew->tm_mon +  1;
    day   = timeinfoNew->tm_mday;
    hour  = timeinfoNew->tm_hour;
    minute= timeinfoNew->tm_min;

    //point B
}

When printing rawtime variable in point B, I can verify that 300 seconds have been added to it succesfully. However, after converting UTC to Broken-down time format using gmtime() Linux system function and printing the resulting values (year, month, day, hour and minute) in point B, I noticed an undefined behaviour for gmtime() function -- it sometimes converts UTC succesfully, but sometimes not.

What could make its behaviour undefined ? or Is there something else wrong in my code ?

Thanks.

[aryan1]

To give an example to false looking result of gmtime(), given the following year/month/day/hour/minute input:

2010/04/02/10/00

The result returned by gmtime() is:

2010/04/02/07/05, where 2010/04/02/10/05 is expected.

[treuss]

The argument of mktime is a record representing the local time (according to your set timezone). gmtime on the other hand converts to UTC timezone. So according to your example result, your system's timezone is 3 hours off UTC.

[aryan1]

The argument of mktime is a record representing the local time (according to your set timezone). gmtime on the other hand converts to UTC timezone. So according to your example result, your system's timezone is 3 hours off UTC.

My question was something else.

Can you imagine any factor which may cause gmtime() or localtime() functions to behave differently for the same input at different times ?

That is, I sometimes see "2010/04/02/07/05" and sometimes "2010/04/02/10/05" as output for the same input, i.e. 2010/04/02/10/00. I noticed this behaviour for both gmtime() and localtime() functions.

[treuss]

I can only imagine that mktime runs differently because of different environment settings. E.g. if you run as user1 you might have TZ variable set, if you run as user2 you might have not and thus /etc/timezone is used.

But probably you are running as the same user, so that's not the case.

I recommend checking for wormholes outside your window.

[aryan1]

I can only imagine that mktime runs differently because of different environment settings. E.g. if you run as user1 you might have TZ variable set, if you run as user2 you might have not and thus /etc/timezone is used.

But probably you are running as the same user, so that's not the case.

I recommend checking for wormholes outside your window.

This problem seems to be weird.

At one execution of my program, time increment works fine, but on another run of my program at a later time, it does not. (I run it with the same user)

After calling localtime() function, I check the tm_zone field (set by localtime()) of its return value, i.e., struct tm*, and observe it to be EET, which seems to be correct.

What do you mean by wormhole and how can I check for them ?

[hoxsiew]

I think that was a joke. A wormhole in SciFi is a rift in the space-time continuum.

[treuss]

This problem seems to be weird.

At one execution of my program, time increment works fine, but on another run of my program at a later time, it does not. (I run it with the same user)

I'm not 100% sure if this is the problem, but you are not setting timeinfo.tm_isdst, which means the value of the field is undefined when calling mktime. Try explicitly setting timeinfo.tm_isdst to -1 (information not available) to have the system try to figure out itself whether DST is in effect or not.

What do you mean by wormhole and how can I check for them ?

They look something like this.