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 future
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 a
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 rethink
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
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 difference
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
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
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
Rob Richardson rob.richard...@rad-con.com 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
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
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 use the
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 -- zones.
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 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 away
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 into a
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
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
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 your
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 what
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,
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:
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 time
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 expecting
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 likely to
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 it
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
26 matches
Mail list logo
