Re: date_trunc() in a specific time zone

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

In response to

Responses

Browse pgsql-hackers by date

  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