From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
Cc: | vik(dot)fearing(at)2ndquadrant(dot)com, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, andreas(at)proxel(dot)se, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: date_trunc() in a specific time zone |
Date: | 2018-10-29 18:46:15 |
Message-ID: | 18074.1540838775@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> writes:
> I guess the issue is that for w/o-tz, you need an extra parameter to
> say what you're assuming you started with.
Yeah, that's basically what I was wondering. I suppose we could imagine
a 4-argument function to cover that case, but I do not think it's worth
the trouble, given that there are other ways to do it.
BTW, I'd been hoping that we could avoid rotate-to-local-and-back
in Vik's desired case, but after further thought I suspect the only
real optimization that's possible compared to writing it out with
two AT TIME ZONE constructs is to do the zone name lookup just once.
As an example, truncating to a day-or-larger boundary could result in
shifting to a different UTC offset than you started with, due to crossing
a DST boundary.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-10-29 19:02:18 | Re: replication_slots usability issue |
Previous Message | Andres Freund | 2018-10-29 18:26:56 | Re: replication_slots usability issue |