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
14 matches
Mail list logo
