On Behalf Of Christopher Browne
Sent: Thursday, March 17, 2005 6:23 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Best practices: Handling Daylight-saving time
Don't use DST.
Use GMT/UTC.
That makes the issue go away.
--
(reverse (concatenate 'string "gro.m
Don't use DST.
Use GMT/UTC.
That makes the issue go away.
--
(reverse (concatenate 'string "gro.mca" "@" "enworbbc"))
http://cbbrowne.com/info/slony.html
Signs of a Klingon Programmer #2: "You question the worthiness of my
code? I should kill you where you stand!"
---(
> > This would be news to me. I don't think it's possible to *not* have a
> > timezone set on a session. The server will have a default timezone
> > based either on the local (server) system time or the setting of the
> > timezone variable in postgresql.conf. Additionally, libpq
> > applications
>> 3) If I retrieve them without "at time zone" I will get them with
>> the time zone that was stored in the first place, right ?
> [...]
>
> This would be news to me. I don't think it's possible to *not* have a
> timezone set on a session. The server will have a default timezone
> based either
For the record, if people search the archives for solutions.
Problem:
You need the time zone in use for
when data was previously inserted/updated.
Discussion:
> > > As others have mentioned, store timestamps on the server in UTC,
> >
> > 1) As long as I store them as I should
> > not need to
On Sat, Mar 12, 2005 at 12:22:38PM -0500, Randall Nortman wrote:
>
> Anyway, afaik, Postgres does not store the "original" timezone
> anywhere, and so could not possibly retrieve it. I think the only
> physical difference between the "timestamp" and "timestamp with time
> zone" types is in the sy
Randall Nortman <[EMAIL PROTECTED]> writes:
> Anyway, afaik, Postgres does not store the "original" timezone
> anywhere, and so could not possibly retrieve it. I think the only
> physical difference between the "timestamp" and "timestamp with time
> zone" types is in the system catalog; the manual
On Sat, Mar 12, 2005 at 05:44:52PM +0100, Karsten Hilbert wrote:
> On Fri, Mar 11, 2005 at 01:43:21PM -0500, Randall Nortman wrote:
>
> > As others have mentioned, store timestamps on the server in UTC,
>
> 1) As long as I store them as I should
> not need to care what they are stored as on the
On Fri, Mar 11, 2005 at 01:43:21PM -0500, Randall Nortman wrote:
> As others have mentioned, store timestamps on the server in UTC,
1) As long as I store them as I should
not need to care what they are stored as on the backend as
long as I provide the proper timezone for the client location.
Cor
Instead of spikes or dips, with your method customers will just be
confused as to why the labels skip an hour, or have two of the same
hour. It would make for a more accurate graph though, your right.
6 of 1, half a dozen of another I guess.
On Fri, 2005-03-11 at 23:33 +, Andrew - Supernews
On 2005-03-11, Mike Benoit <[EMAIL PROTECTED]> wrote:
> Here is a scenario I ran in to with collecting bandwidth usage and
> displaying it back in graph form to customers.
>
> You can store the timestamps in GMT, but the customer wants to see when
> spikes happen in his localtime, which most likely
On Fri, 2005-03-11 at 13:47, Mike Benoit wrote:
> Not exactly...
>
> Here is a scenario I ran in to with collecting bandwidth usage and
> displaying it back in graph form to customers.
>
> You can store the timestamps in GMT, but the customer wants to see when
> spikes happen in his localtime, wh
Not exactly...
Here is a scenario I ran in to with collecting bandwidth usage and
displaying it back in graph form to customers.
You can store the timestamps in GMT, but the customer wants to see when
spikes happen in his localtime, which most likely has DST. So twice a
year, you are either compr
On Fri, Mar 11, 2005 at 03:25:28PM +0100, Egy?d Csaba wrote:
> Hi All,
> I'd like to ask your opininon about how to handle DST on an 7/24 system.
> Where should it be handled: on the server side or on the client side? And
> how could I (at all could I???) make it transparent?
As others have menti
On Friday 11 March 2005 6:25 am, Együd Csaba wrote:
> Hi All,
> I'd like to ask your opininon about how to handle DST on an 7/24
> system. Where should it be handled: on the server side or on the
> client side? And how could I (at all could I???) make it
> transparent?
>
> Or we must bow to the fac
[EMAIL PROTECTED] (Együd Csaba) wrote:
> I'd like to ask your opininon about how to handle DST on an 7/24 system.
> Where should it be handled: on the server side or on the client side? And
> how could I (at all could I???) make it transparent?
Don't use DST.
Use GMT/UTC.
That makes the issue g
On Fri, Mar 11, 2005 at 03:25:28PM +0100, Együd Csaba wrote:
> Hi All,
> I'd like to ask your opininon about how to handle DST on an 7/24 system.
> Where should it be handled: on the server side or on the client side? And
> how could I (at all could I???) make it transparent?
>
> Or we must bow t
On Fri, Mar 11, 2005 at 15:25:28 +0100,
Együd Csaba <[EMAIL PROTECTED]> wrote:
> Hi All,
> I'd like to ask your opininon about how to handle DST on an 7/24 system.
My advice would be to use GMT and not have to worry about DST while
collecting data. When displaying data you might convert the time
18 matches
Mail list logo
