mktime and tm_isdst

Question

I saw a lot of different views so thought of asking here.

I read man mktime:

 (A positive or zero value for tm_isdst causes mktime() to presume initially
 that summer time (for example, Daylight Saving Time) is or is not in
 effect for the specified time, respectively.  A negative value for
 tm_isdst causes the mktime() function to attempt to divine whether summer
 time is in effect for the specified time. 

My question is, shouldn't tm_isdst be kept as -1 to let the system decide if its dst or not and that way the code becomes dst agnostic?

Am I missing something?

Answer 1

You should avoid setting tm_isdst to -1 if possible. The system can't always determine DST status from date and time alone. It is ambiguous the hour before and after DST ends. For example, if you pass mktime() 1:30 AM November 4, 2012, that's not enough information to get a correct time_t value from mktime(). Usually I have seen mktime() assume standard time in the case that it is ambiguous, but I haven't seen any documentation that guarantees that behavior on all platforms. 1:30 AM November 4, 2012 with tm_isdst == 1 would be 1 hour before, because the hour 1:00:00 to 1:59:59 repeats.

#include <stdio.h>
#include <time.h>

int main()
{
    time_t daylight, standard;
    struct tm timestr;
    double diff;

    timestr.tm_year = 2012 - 1900;
    timestr.tm_mon = 11 - 1;
    timestr.tm_mday = 4;
    timestr.tm_hour = 1;
    timestr.tm_min = 30;
    timestr.tm_sec = 0;

    /* first with standard time */
    timestr.tm_isdst = 0;
    standard = mktime(&timestr);

    /* now with daylight time */
    timestr.tm_isdst = 1;
    daylight = mktime(&timestr);

    diff = difftime(standard, daylight);

    printf("Difference is %f hour(s)", diff/60.0/60.0);

    return 0;
}

This produces:

Difference is 1.000000 hour(s)

Both are November 4, 2012 1:30 AM, however both are two distinct time_t values, 1 hour apart.

mktime() essentially has 2 outputs:

• time_t
• repaired time struct

The time struct is both an input and output. It is modified by mktime() to return all struct members to nominal ranges. For example, if you increment the tm_hour member += 500, that means increment the time by 500 hours. The tm_hour member will be changed to a value 00 to 23, and the tm_day, tm_mday, and etc will all be adjusted accordingly. tm_isdst is also both an input and output. Its values are as follows:

• 1 (DST in effect, i.e. daylight time)
• 0 (DST not in effect, i.e. standard time)
• -1 (Unknown DST status)

So mktime() will output either a 1 or 0 for tm_isdst, never -1.

-1 is a possible input, but I would think of it as meaning "Unknown". Don't think of it as meaning "determine automatically", because in general, mktime() can't always determine it automatically.

The explicit DST status (0 or 1) should come from something external to the software, for example store it in the file or database, or prompt the user.

Answer 2

I believe the original reason for that is some timezones do not have daylight savings time. Since mktime is not async-safe nor is it re-entrant allows the implementation to store the current value of daylight savings in the POSIX extern char tzname[2], indexed by daylight [0 or 1]. This means tzname[0]="[std TZ name]" and tzname="[daylight TZ name, e.g. EDT]"

See your tzset() man page for more information on this. Standards conforming mktime() is required to behave as though it called tzset() anyway. This kind of obviates the use of tm_isdst, IMO.

Bottom line: your particular implementation and timezone(s) would dictate whether you would use -1, 0, or 1 for tm_isdst. There is no one default correct way for all implementations.

Answer 3

I think that you should indeed use -1 for the tm_isdst field unless you have the information about the type of time you are dealing with.

For example, in California we still have PST and PDT. If you are parsing a date and that timezone information is present, then you should set the tm_isdst accordingly. As Jim McNamara mentioned, these names are available in the tzname[] array after a call to tzset().

For example, the following C++ code write PST/PDT:

int main(int argc, char * argv [])
{
    tzset();
    std::cerr << tzname[0] << "/" << tzname[1] << "\n";

    return 0;
}

The offset in the tzname[] array corresponds to the value of tm_isdst. (PST -- Pacific Standard Time, tm_isdst = 0, and PDT, Pacific Daylight Time, tm_isdst = 1.)

If you do not have the timezone information in your input, then using -1 is the best choice. You run into a problem only when the date corresponds to the day and time when the change happens. As Rich Jahn explains, on Nov 4, 2012, he had a time change between standard and daylight time and around that time, gmtime() has to make a choice and it is not unlike the opposite of what you'd expect. That being said, it only happens for a total of 2 hours in a year and in the middle of the night. So unless you are working on a critical type of software where date is very important, it probably won't matter much.

So, as a recap:

• if you have the timezone attached to the date you want to convert, use that information to determine the value of tm_isdst (that being said, I'm not too sure how you handle that in case you have to support all timezones... the tzname[] array only gives you the user's current timezone.)
• in all other cases, use -1