On 22 Mar 2010, at 14:08, Rob Richardson wrote:
> One question: We have customers all over the world. It would be best
> if we could rely on the operating system (usually Windows Server 2003)
> to tell us what time zone we're in, rather than asking for a specific
> timezone when we want to know
Tom,
You said, "It seems to me that you're not entirely understanding how
timestamps work in Postgres." That is an understatement!
Thank you very much for your explanation. I have forwarded it to the
other members of my development group, with my suggestion that we follow
your ideas for futur
Tom Lane wrote:
> If my guesses are correct, then the minimum change to avoid this type
> of problem in the future is to change UTCTimestamp to be declared as
> timestamp WITHOUT time zone, so that you don't get two extra zone
> rotations in there. However, I would strongly suggest that you rethi
"Rob Richardson" writes:
> Our database monitors the progression of steel coils through the
> annealing process. The times for each step are recorded in wallclock
> time (US eastern time zone for this customer) and in UTC time. During
> standard time, the difference will be 5 hours, and during d
On 03/15/2010 12:40 PM, Rob Richardson wrote:
Greetings!
Our database monitors the progression of steel coils through the
annealing process. The times for each step are recorded in wallclock
time (US eastern time zone for this customer) and in UTC time. During
standard time, the difference wil
Rob Richardson wrote:
Greetings!
...
I just looked at the record for a charge for which heating started just
after 9:00 Saturday night, less than 3 hours before the change to
daylight savings time. The UTC time stored for this event is six hours
later!
The function that writes these times f
Thanks for the try, Justin, but that doesn't seem to be the problem.
The query generates the same results on my customer's machine. Besides,
I think your theory would only hold up if there were two machines
involved. There aren't.
RobR
--
Sent via pgsql-general mailing list (pgsql-general@pos
On 3/15/2010 2:40 PM, Rob Richardson wrote:
> Greetings!
>
> Our database monitors the progression of steel coils through the
> annealing process. The times for each step are recorded in wallclock
> time (US eastern time zone for this customer) and in UTC time. During
> standard time, the differe
Greetings!
Our database monitors the progression of steel coils through the
annealing process. The times for each step are recorded in wallclock
time (US eastern time zone for this customer) and in UTC time. During
standard time, the difference will be 5 hours, and during daylight
savings time t
On Friday 21 April 2006 05:47 pm, Tom Lane <[EMAIL PROTECTED]> thus
communicated:
--> Terry Lee Tucker <[EMAIL PROTECTED]> writes:
--> > I need to know if there is a convienient way of establishing whether
DST is --> > active within a function dealing with adjusting timestamps to
other time -->
Terry Lee Tucker <[EMAIL PROTECTED]> writes:
> I need to know if there is a convienient way of establishing whether DST is
> active within a function dealing with adjusting timestamps to other time
> zones. The problem is that if I have the following timestamp:
> '04/21/2006 17:05 EDT'
> and I us
Hello List:
I need to know if there is a convienient way of establishing whether DST is
active within a function dealing with adjusting timestamps to other time
zones. The problem is that if I have the following timestamp:
'04/21/2006 17:05 EDT'
and I use the timezone() function in the followi
On Sunday 31 October 2004 11:44 am, Tom Lane wrote:
> Randall Nortman <[EMAIL PROTECTED]> writes:
> > Ah, I see now. PostgreSQL is behaving a bit differently than I
> > expected. The timestamp string above is ambiguous in the
> > timezone US/Eastern -- it could be EST or EDT. I was expecting
> >
On Mon, Nov 01, 2004 at 07:08:39PM +0100, Martijn van Oosterhout wrote:
> For the parsing integer issue it may have worked, but this is another
> kettle of fish. I don't think you can do this as a simple switch, it
> would have to set during the initdb and not allowed to be changed
> afterwards. I
On Mon, Nov 01, 2004 at 01:57:38PM -0300, Vinko Vrsalovic wrote:
> On Sun, Oct 31, 2004 at 05:55:23PM -0500, Tom Lane wrote:
> > One point here is that timestamp-to-timestamptz datatype conversion will
> > be affected by whatever we choose. While it's easy to say "reject it"
> > for data coming in
On Sun, Oct 31, 2004 at 05:55:23PM -0500, Tom Lane wrote:
[...]
> I'm inclined to think that rejecting impossible or ambiguous input
> without a zone is reasonable (and it would go along with the changes
> we made in 7.4 to tighten up datetime field order assumptions).
> But I don't want to take a
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Sun, Oct 31, 2004 at 04:14:52PM -0500, Tom Lane wrote:
>> That line of argument leads directly to the conclusion that we shouldn't
>> allow timezone-less input strings at all, since it's unlikely that
>> anyone would code their app to append a
On Sun, Oct 31, 2004 at 04:14:52PM -0500, Tom Lane wrote:
> That line of argument leads directly to the conclusion that we shouldn't
> allow timezone-less input strings at all, since it's unlikely that
> anyone would code their app to append a timezone spec only during the
> two hours a year when i
Randall Nortman <[EMAIL PROTECTED]> writes:
> On Sun, Oct 31, 2004 at 02:44:51PM -0500, Tom Lane wrote:
>> Actually, the intended and documented behavior is that it should
>> interpret an ambiguous time as local standard time (e.g., EST not EDT).
> I'm finding it hard to see how either way is like
On Sun, Oct 31, 2004 at 02:44:51PM -0500, Tom Lane wrote:
> Randall Nortman <[EMAIL PROTECTED]> writes:
> > Ah, I see now. PostgreSQL is behaving a bit differently than I
> > expected. The timestamp string above is ambiguous in the timezone
> > US/Eastern -- it could be EST or EDT. I was expecti
Randall Nortman <[EMAIL PROTECTED]> writes:
> Ah, I see now. PostgreSQL is behaving a bit differently than I
> expected. The timestamp string above is ambiguous in the timezone
> US/Eastern -- it could be EST or EDT. I was expecting PostgreSQL to
> resolve this ambiguity based on the current tim
On Sun, Oct 31, 2004 at 12:47:31PM -0500, Tom Lane wrote:
> Randall Nortman <[EMAIL PROTECTED]> writes:
> > I can't reproduce the error without messing up my clock, but from my
> > logs, here's the text of the SQL sent to the server:
>
> > insert into sensor_readings_numeric (sensor_id, reading_ts
Randall Nortman <[EMAIL PROTECTED]> writes:
> I can't reproduce the error without messing up my clock, but from my
> logs, here's the text of the SQL sent to the server:
> insert into sensor_readings_numeric (sensor_id, reading_ts, reading,
> min, max) values (3, '2004-10-31 01:00:00', 0.540602, 0
On Sun, Oct 31, 2004 at 11:52:03AM -0500, Tom Lane wrote:
> Randall Nortman <[EMAIL PROTECTED]> writes:
> > My suspicion is that Postgres calculates the local offset from UTC
> > only once per session, during session initialization.
>
> This is demonstrably not so. We might be able to figure out
Randall Nortman <[EMAIL PROTECTED]> writes:
> My suspicion is that Postgres calculates the local offset from UTC
> only once per session, during session initialization.
This is demonstrably not so. We might be able to figure out what
actually went wrong, if you would show us the exact commands yo
I assume I'm not the first person to have encountered this, but I
couldn't find anything in the FAQ or on the mailing lists recently.
My apologies if this is already documented somewhere...
My application logs data to a Postgres table continuously (once every
15 seconds), maintaining a persistent
26 matches
Mail list logo
