Re: Win32 timezone matching
От | Stefan Kaltenbrunner |
---|---|
Тема | Re: Win32 timezone matching |
Дата | |
Msg-id | 4BBCAA02.5020207@kaltenbrunner.cc обсуждение исходный текст |
Ответ на | Re: Win32 timezone matching (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Win32 timezone matching
|
Список | 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 по дате отправления: