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
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 |