| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | James Cloos <cloos(at)jhcloos(dot)com> |
| Cc: | Steve Crawford <scrawford(at)pinpointresearch(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: now() vs 'epoch'::timestamp |
| Date: | 2015-04-02 17:34:44 |
| Message-ID: | CAKFQuwYS7Z5RscWxsNYe3-ON=CouV4Nbw_0vzprv0m+TxDFrEQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, Apr 2, 2015 at 10:27 AM, James Cloos <cloos(at)jhcloos(dot)com> wrote:
> >>>>> "SC" == Steve Crawford <scrawford(at)pinpointresearch(dot)com> writes:
>
> SC> Very convoluted calculation as others have noted. As to why it is
> SC> "off", you are casting one part of the statement to an integer thus
> SC> truncating the microseconds but are not doing the same on the other
> SC> side of the calculation.
>
> It wasn't the microsecond difference I asked about, it was the 6 hour
> difference.
>
> The original, ancient code I used needed to return integer seconds. And
> it always gave answers consistant with date +%s.
>
> What I haven't determined is why converting back is off by 21600 seconds.
>
>
What timezone is your server set to - and/or the client requesting the
calculation?
I haven't looked to see if that is a plausible explanation but if you are
+/- 6hrs from UTC...
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Crawford | 2015-04-02 18:01:38 | Re: now() vs 'epoch'::timestamp |
| Previous Message | James Cloos | 2015-04-02 17:27:35 | Re: now() vs 'epoch'::timestamp |