Tom Lane writes:> Pete Forman <pete.forman@westerngeco.com> writes:> > Thinking about that a bit more, I think that
tm_isdstshould not> > be written into.> > IIRC, setting isdst to -1 was necessary to get the right behavior> across DST
boundarieson more-mainstream systems. I do not think> it's acceptable to do worse on systems with good time libraries
in>order to improve behavior on fundamentally broken ones.
A footnote in the C89 (and C99) standard says:
Thus, a positive or zero value for tm_isdst causes the mktime function to presume initially that Daylight
Saving Time, respectively, is or is not in effect for the specified time. A negative value causes it to
attemptto determine whether Daylight Saving Time is in effect for the specified time.
So tm_isdst being input as 0 or 1 is not forcing the choice of what it
will be on output. It can be important at the end of DST when local
times repeat and the only way to distinguish them is the setting of
this flag.
That is borne out by my observations.
Setting tm_isdst to -1 before calling mktime can make a difference to
the result when the input and result have different DST flags.
It is fairly arbitrary what the answer to this question is: if six
months is subtracted from a to give b, should a.local.hour =
b.local.hour or should a.utc.hour = b.utc.hour? If you want the
former then set tm_isdst = -1 before calling mktime. I'm out of time
now but I'll try and look for some guidance in the SQL standards.
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.