Re: AW: Re: tinterval - operator problems on AIX

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.