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):
Steps to Reproduce:
1. Run the attached program
2. Look at the output
3. Note that the third and fourth times don't match
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.