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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/14/07 15:23, Vivek Khera wrote:
>
> On Mar 12, 2007, at 6:08 PM, Martijn van Oosterhout wrote:
>
>> On Mon, Mar 12, 2007 at 01:13:42PM -0600, Ed L. wrote:
>>> Would I be correct in understanding that every pre-8.0 cluster
>>> must be restarted
On Mar 12, 2007, at 6:08 PM, Martijn van Oosterhout wrote:
On Mon, Mar 12, 2007 at 01:13:42PM -0600, Ed L. wrote:
Would I be correct in understanding that every pre-8.0 cluster
must be restarted in order for the OS changes to take affect?!?
Possibly, I imagine many C libraries would cache th
Martijn van Oosterhout writes:
> On Mon, Mar 12, 2007 at 01:13:42PM -0600, Ed L. wrote:
>> Would I be correct in understanding that every pre-8.0 cluster
>> must be restarted in order for the OS changes to take affect?!?
> Possibly, I imagine many C libraries would cache the timezone data over
>
On Monday March 12 2007 4:08 pm, Martijn van Oosterhout wrote:
> On Mon, Mar 12, 2007 at 01:13:42PM -0600, Ed L. wrote:
> > Would I be correct in understanding that every pre-8.0
> > cluster must be restarted in order for the OS changes to
> > take affect?!?
>
> Possibly, I imagine many C libraries
On Mon, Mar 12, 2007 at 01:13:42PM -0600, Ed L. wrote:
> Would I be correct in understanding that every pre-8.0 cluster
> must be restarted in order for the OS changes to take affect?!?
Possibly, I imagine many C libraries would cache the timezone data over
a fork and might not motice the changes
On Monday March 12 2007 1:07 pm, Ed L. wrote:
> Does this mean that we need to restart these clusters in order
> to get the timezone updates from the OS? Are they cached in
> the postmaster?
Nevermind. I just found it via googling.
Would I be correct in understanding that every pre-8.0 cluster
We have a 7.4.6 cluster which has been running on an HP B.11.00
box for quite sometime. The IT group applied daylight savings
patches to the OS, but the cluster is still showing the
incorrect timezone:
$ psql -c "select now()"
now
---
2
Joseph Shraibman writes:
> Robert Treat wrote:
>
>> If you are running pre-8.0 versions you need to update your operating system
>> (as you indicated). If you running an any 8.x version, you need to be on
>> the most current corresponding 8.x.y release.
>>
> So what happens if you have an old os
> >> So what happens if you have an old os with a new postgresql install?
> >> Will CURRENT_TIMESTAMP always return the correct value even if the
> >> system 'date' command is showing the wrong time?
>
> > Yes.
>
> Unless the user changes the system's clock setting (ie, its notion of
> the curr
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Joseph Shraibman wrote:
>> So what happens if you have an old os with a new postgresql install?
>> Will CURRENT_TIMESTAMP always return the correct value even if the
>> system 'date' command is showing the wrong time?
> Yes.
Unless the user changes th
Joseph Shraibman wrote:
> Robert Treat wrote:
>
> > If you are running pre-8.0 versions you need to update your operating
> > system
> > (as you indicated). If you running an any 8.x version, you need to be on
> > the
> > most current corresponding 8.x.y release.
> >
> So what happens if you
Robert Treat wrote:
If you are running pre-8.0 versions you need to update your operating system
(as you indicated). If you running an any 8.x version, you need to be on the
most current corresponding 8.x.y release.
So what happens if you have an old os with a new postgresql install?
Will C
> I was trying to avoid getting into the gory details of which releases
> had which timezone fixes, but it seems I can't avoid it. The new FAQ
> item has the details:
>
> USA daylight saving time changes are included in PostgreSQL release
> 8.0.[4+], and all later major releases, e.g. 8.1
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > USA daylight saving time changes are included in PostgreSQL
> > release 8.0.[4+], and all later major releases, e.g. 8.1. Canada and
> > Western Australia changes are included in 8.0.[10+], 8.1.[6+], and
> > all later major releases. PostgreS
Bruce Momjian wrote:
> USA daylight saving time changes are included in PostgreSQL
> release 8.0.[4+], and all later major releases, e.g. 8.1. Canada and
> Western Australia changes are included in 8.0.[10+], 8.1.[6+], and
> all later major releases. PostgreSQL releases prior to 8.0 use the
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Steve Crawford wrote:
>> 1. What, exactly, was the point of moving away from the system zoneinfo
>> files and requiring PG admins to maintain yet another apparently
>> identical set of files?
The fact that not all systems use the zic database. We were t
Steve Crawford wrote:
> > I was trying to avoid getting into the gory details of which releases
> > had which timezone fixes, but it seems I can't avoid it. The new FAQ
> > item has the details:
> >
> > USA daylight saving time changes are included in PostgreSQL release
> > 8.0.[4+], and
Ed L. wrote:
>
> >From the FAQ:
>
>
> 1.14) Will PostgreSQL handle recent daylight saving time changes
> in various countries?
>
> PostgreSQL versions prior to 8.0 use the operating system's
> timezone database for daylight saving information. All current
> versions of Po
On Tuesday 06 February 2007 13:16, Ed L. wrote:
> From the FAQ:
>
>
> 1.14) Will PostgreSQL handle recent daylight saving time changes
> in various countries?
>
> PostgreSQL versions prior to 8.0 use the operating system's
> timezone database for daylight saving information. Al
From the FAQ:
1.14) Will PostgreSQL handle recent daylight saving time changes
in various countries?
PostgreSQL versions prior to 8.0 use the operating system's
timezone database for daylight saving information. All current
versions of PostgreSQL 8.0 and later contain up-
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
Hi all,
I'm wondering if anyone has scripts or knows of any tools which will detect
the next DST change, and setup a cronjob to be run just before it?
This is so we can have certain types of data which are stored in the database
as localtime, updated to still be correct during DST and after.
47 matches
Mail list logo
