Red Hat Bugzilla – Bug 131108
unexpected one-hour offset in time conversions
Last modified: 2007-11-30 17:10:48 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: I'm not sure what is going on here. It looks to me like one of the time functions is stepping on the DST flag. Run the attached program to see. Version-Release number of selected component (if applicable): 2.3.3 How reproducible: Always Steps to Reproduce: 1. Run the attached program 2. Look at the output 3. Note that the third and fourth times don't match Additional info:
Created attachment 103171 [details] Demonstrates an apparent bug in the time functions
What is unexpected there? "The mktime() function shall convert the broken-down time, expressed as local time,"... I've verified Solaris gives exactly the same results as Linux.
This is not a bug. The C standard specifies that mktime consults the fields that the C standard specifies in struct tm, including tm_isdst. The fields such as tm_zone and tm_gmtoff that give information about what timezone to apply are extensions not specified by the C standard. mktime cannot consult these fields, as a standard C program defining its own struct tm might leave them as uninitialized garbage and be correct in doing so and expecting mktime to operate on the standard struct tm fields in the local time zone. If your local timezone (from TZ or /etc/localtime) has one-hour DST rules and your struct tm says tm_isdst, then it indicates the time the standard struct tm fields say, with the local timezone's UTC offset + 1 hour for DST.
Then I request that a WARNING be added to the mktime() manual page explaining this situation.
Don't think a warning is necessary-- man page seems pretty clear to me, and I don't see a lot of people tripping over this.