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.
–
–
–
–
–
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.
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
–
–
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
