"Lane Van Ingen" <lvaningen@ESNCC.com> writes:
> Looks like I may have just solved my own problem: I noticed that in Date
and
> Time Properties of the Windows clock, on the Time Zone tab, there is a
> checkbox
> called "Automatically adjust clock for daylight savings time changes".
> If that box is unchecked, PostgreSQL must try to compensate, because on
> those
> platforms that are unchecked is where I am having the problem of now()
> returning
> a date that is one hour later. It now works correctly.
Hmm. I think the way that the code in pgtz.c is set up, it just assumes
that either "Eastern Standard Time" or "Eastern Daylight Time" should
map to our US/Eastern timezone (which is a DST-aware zone). Running
your system in non-DST-aware mode is what's confusing it --- the offset
to GMT is an hour different than it "should be" at this time of year.
Should pgtz.c try to detect this situation and handle it by mapping to a
non-DST-aware internal timezone?
regards, tom lane
I think this is a simple case of misconfiguration and I suspect fiddling
with it would just open up the possibility of more errors. If you say
you are in a DST timezone and you don't check the DST checkbox, and you
set the time to summer time then you're asking for trouble. I would not
be at all surprised if the machine's idea of UTC was an hour out
(Windows boxes keep the RTC on local time, not UTC, which is just horrid).
cheers
andrew (dunstan)
If I am following this correctly, I may have solved the problem for myself
in
the Eastern time zone, but this application gets deployed around the world,
anywhere at sea that a vessel can go. While I think the vessel sets its time
based on its home port and keeps it that way through voyage(s), I am won-
dering if handling of time is still going to give me problems outside of
time
zones where DST is being observed.
Lane Van Ingen