Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I have the following doubt on the usage of tm_isdst flag in the tm structure. As per man pages and googled results, I understand that its value is interpreted as follows

A. A value of 0 indicates DST is not in effect for the represented time

B. A value of 1 indicates DST is in effect

C. A value of -1 causes mktime to check whether DST is in effect or not.

It is this third point which is confusing me. My doubt is how mktime can figure out whether DST has to be applied or not accurately.

For example

My Time Zone = GMT + 3:00
DST shifting = +1 Hour at 5:00 AM in January (to keep it simple)
Current UTC time = "01/Jan/2012 00:00:00"
UTC time in seconds time_t timetUTC = X seconds
Hence my time is = "01/Jan/2012 03:00:00"
As time passes, my time value changes as follows
"01/Jan/2012 04:00:00"            (X + 1 * 60 * 60)
"01/Jan/2012 05:00:00"            (X + 2 * 60 * 60)
"01/Jan/2012 05:59:59"            (X + 2 * 60 * 60 + 59)
"01/Jan/2012 05:00:00"            (X + 3 * 60 * 60)
"01/Jan/2012 06:00:00"            (X + 4 * 60 * 60)
As per my understanding
tm tmMyTime = localtime_r(X + 2 * 60 * 60) will set tmMyTime.tm_isdst to 0
tm tmMyTime = localtime_r(X + 3 * 60 * 60) will set tmMyTime.tm_isdst to 1
This way, even though all other components of tm structure are equal in both cases,
mktime(tmMyTime) can return proper UTC value, depending on tm_isdst value.
Now, if I set tmMyTime.tm_isdst = -1, what value would mktime return? I read about TZ variable, time database etc etc. In spite of all that, logically how can mktime() figure out whether to apply DST correction or not for those tm values that can occur twice?
We do not have DST in our time zone. Hence I am not very sure whether my understanding
is correct. Please correct me if I am wrong. Your help is much appreciated.
In short: it is implementation dependent.
mktime knows the DST rules by checking the locale.
For the bigger part of the year, mktime can figure out if DST is to be applied for a particular local time. The problem is indeed the "duplicate" hour when DST shifts backwards (in your example 05:00:00 - 05:59:59). For this local time range, given tm_isdst = -1, mktime cannot know if DST is in effect or not. Which one of these is chosen, differs from one implementation to another. With the GNU version of mktime, the UTC before the shift is returned.
                Thanks Pat. At best mktime can do only that much is what I also felt. But nowhere (including man page) there was a clear description regarding handling of this ambiguous 1 Hour. I became more confused on noticing a deliberate resetting of this flag to -1 in our code base every time after a "tm = localtime_r(time_t)". At least in this case I thought the flag should be left untouched. Also, I feel that implementations should clearly state this behavior in man page. Either a standard function should give always correct result or throw error on failure or at least mention deviations in man page.
– programmist
                May 14, 2012 at 6:22
                Good answer. The problem here is that if all the user passes us is something akin to a struct tm, and our only interface to timezone information is Posix mktime(), then we can't portably code around the problem ourselves either. Either we can force the user to specify which "November 3, 2013 at 1:30:00 AM" they are giving us, or we might as well just set tm_isdst=-1 and hope for the best.
– T.E.D.
                Sep 9, 2013 at 18:20
tm_isdst cannot in general resolve ambiguous times. That's because many timezones have transitions (one-time) without jumping from dst to nodst, just changing offset and zone abbreviation. So both times (before and after transition) have the same tm_isdst.
Some other zones changes tm_isdst when switching summer/winter time but doesn't change abbreviation (Australia/Melbourne for example).
I think it's going to be somewhat dependent on your platform.  In Windows, at least, the mktime() documentation states "The C run-time library assumes the United States’s rules for implementing the calculation of Daylight Saving Time", so it has a table of rules somewhere where it can determine when DST started / ended in any given year.
You're lucky not to have DST where you are.  In my world, which is real-time data acquisition and presentation, DST is a big nuisance!
                Thanks for the reply. However, it is still not clear how mktime() can do that. Since two UTC time_t values can have same tm value in local timezone (except for is_dst), and if I reset this flag alone to -1, logically mktime() function doesn't have any clue as to which of the UTC values it should convert it back to.
– programmist
                May 13, 2012 at 12:06
        
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.