Re: bug in date_part() function in 6.5.2, 7.0.2 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: bug in date_part() function in 6.5.2, 7.0.2
Date
Msg-id 15506.968370675@sss.pgh.pa.us
Whole thread Raw
In response to Re: bug in date_part() function in 6.5.2, 7.0.2  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List pgsql-bugs
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>>>>> Looks to me like an off-by-one kind of problem in deciding which
>>>>> timezone applies to midnight of a transition day.

> 2) Convert to an integer "Unix system time".

> 3) Rotate by 12 hours (to UTC noon!). This is supposed to ensure that we
> stay in the correct day after conversion to local time *no matter what
> time zone we are actually in*, but is likely the problem in this edge
> case.

> 4) Call localtime() to fill in the fields of a tm structure. This is how
> I get ahold of the time zone (which is not known before this step). For
> this DST edge case, the time zone is off by one hour :(

> 5) Copy the fields from the result of the call to localtime() into a new
> tm structure, with zeros for time fields.

Seems like you could just skip step 3 and call localtime() with fields
indicating midnight of the specified date.  Then use the complete
localtime result (don't discard any fields) and you should be OK, no?

            regards, tom lane

pgsql-bugs by date:

Previous
From: pgsql-bugs@postgresql.org
Date:
Subject: Select from array slices doesn't work
Next
From: Tom Lane
Date:
Subject: Re: Select from array slices doesn't work