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-08 14:09:00
Message-ID: 24629.968422140@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
>> 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?

> Pretty sure this won't work, since the complete localtime result will
> not be local midnight, which is the expected result.

Actually, now that I go back and reread the man pages, the correct
recipe is
* fill a struct tm with y/m/d, h = m = s = 0, isdst = -1
* call mktime() to produce a time_t
* either use the updated struct tm (mktime() side effect),
or convert the time_t directly to timestamp.

mktime() is an ANSI C requirement, so even though it's not as old as
localtime(), it's probably safe enough.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Lockhart 2000-09-08 14:36:47 Re: bug in date_part() function in 6.5.2, 7.0.2
Previous Message Thomas Lockhart 2000-09-08 05:51:00 Re: bug in date_part() function in 6.5.2, 7.0.2