Re: Win32 timezone matching - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: Win32 timezone matching
Date
Msg-id 4BBCAA02.5020207@kaltenbrunner.cc
Whole thread Raw
In response to Re: Win32 timezone matching  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Win32 timezone matching  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Magnus Hagander wrote:
> On Wed, Apr 7, 2010 at 00:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> On Wed, Apr 7, 2010 at 00:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Oh, another thought here: what is the effect of the combination of this
>>>> with your other proposal to add more timezones to the list?
>>> [ none ]
>> Ah, right, I hadn't looked closely at the logic before.  Still have
>> two comments though:
>>
>> * There are other error conditions that cause "break"s in that loop.
>> Should we change the others?
> 
> The only other error condition is if we find a key but can't open it.
> That indicates something that's *seriously* wrong, so I'm inclined to
> keep that one. The other two break statements are actually for when we
> *find* a match, so they just indicate that we pick the first match
> that we find.

hmm all that code makes me wonder a bit about a more general issue - is 
the "fallback to GMT if we fail to actually make sense of the right 
imezone to use" actually a good idea?
In the case of the person I helped diagnosing the issue pg was bundled 
into some commercial app and the only reason the user immediately 
noticed that something was "wrong" was because the app used something 
like "select now()" to display the current time in the GUI.
I would consider the failure to make sense of the registry on windows or  failure to figure timezone information out a
moreserious issue than a 
 
mere "WARNING" because depending on how you look at the issue it might 
actually cause silent data corruption.


Stefan


pgsql-hackers by date:

Previous
From: Nicolas Barbier
Date:
Subject: Re: system table/view and sequence
Next
From: Tom Lane
Date:
Subject: Re: Win32 timezone matching