From: | Alessandro Gagliardi <alessandro(at)path(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: efficient data reduction (and deduping) |
Date: | 2012-03-01 19:29:00 |
Message-ID: | CAAB3BB+c4+Y5E0hzsfo6fi-y1acOZFYjE+EY2cJmYZM4h0TjpQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
All of our servers run in UTC specifically to avoid this sort of problem.
It's kind of annoying actually, because we're a San Francisco company and
so whenever I have to do daily analytics, I have to shift everything to
Pacific. But in this case it's handy. Thanks for the keen eye though.
On Thu, Mar 1, 2012 at 10:51 AM, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov
> wrote:
> Alessandro Gagliardi <alessandro(at)path(dot)com> wrote:
>
> > hr_timestamp timestamp without time zone,
>
> In addition to the responses which more directly answer your
> question, I feel I should point out that this will not represent a
> single moment in time. At the end of Daylight Saving Time, the
> value will jump backward and you will run through a range of time
> which will overlap existing entries. There is almost never a good
> reason to use TIMESTAMP WITHOUT TIME ZONE -- TIMESTAMP WITH TIME
> ZONE is required if you want the value to represent a moment in
> time.
>
> -Kevin
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alessandro Gagliardi | 2012-03-01 19:30:06 | Re: efficient data reduction (and deduping) |
Previous Message | Alessandro Gagliardi | 2012-03-01 19:28:32 | Re: efficient data reduction (and deduping) |