Skip site navigation (1) Skip section navigation (2)

Re: bug in date_part() function in 6.5.2, 7.0.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>, analyst(at)sibinet(dot)ru, pgsql-bugs(at)postgresql(dot)org
Subject: Re: bug in date_part() function in 6.5.2, 7.0.2
Date: 2000-09-07 23:51:15
Message-ID: 15506.968370675@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)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

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2000-09-08 00:23:49
Subject: Re: Select from array slices doesn't work
Previous:From: pgsql-bugsDate: 2000-09-07 15:56:30
Subject: Select from array slices doesn't work

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group