Win32 timezone matching
in [PgSql]
|
From: Tom Lane on 6 Apr 2010 18:48 Magnus Hagander <magnus(a)hagander.net> writes: > On Wed, Apr 7, 2010 at 00:02, Tom Lane <tgl(a)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? * There is a comment at the head of win32_tzmap[] explaining where the data came from; you need to update that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 7 Apr 2010 06:31 On Wed, Apr 7, 2010 at 00:48, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Magnus Hagander <magnus(a)hagander.net> writes: >> On Wed, Apr 7, 2010 at 00:02, Tom Lane <tgl(a)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. > * There is a comment at the head of win32_tzmap[] explaining where the > data came from; you need to update that. Right. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stefan Kaltenbrunner on 7 Apr 2010 11:51 Magnus Hagander wrote: > On Wed, Apr 7, 2010 at 00:48, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Magnus Hagander <magnus(a)hagander.net> writes: >>> On Wed, Apr 7, 2010 at 00:02, Tom Lane <tgl(a)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 more serious issue than a mere "WARNING" because depending on how you look at the issue it might actually cause silent data corruption. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 7 Apr 2010 11:57 Stefan Kaltenbrunner <stefan(a)kaltenbrunner.cc> writes: > 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? What alternative are you proposing? Failing to start the server doesn't seem like an attractive choice. > I would consider the failure to make sense of the registry on windows or > failure to figure timezone information out a more serious issue than a > mere "WARNING" because depending on how you look at the issue it might > actually cause silent data corruption. Somehow, if you're running a database on windoze, I doubt your data integrity standards are that high. In any case I'd rather get a bleat about "why is the server running in GMT" than "my database won't start". The former will be a lot easier to narrow down. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stefan Kaltenbrunner on 7 Apr 2010 12:20 Tom Lane wrote: > Stefan Kaltenbrunner <stefan(a)kaltenbrunner.cc> writes: >> 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? > > What alternative are you proposing? Failing to start the server doesn't > seem like an attractive choice. why not? we do error out in a lot of other cases as well... Personally I find a hard and clear "something is wrong please fix" much more convinient than defaulting to something that is more or less completely arbitrary but well... > >> I would consider the failure to make sense of the registry on windows or >> failure to figure timezone information out a more serious issue than a >> mere "WARNING" because depending on how you look at the issue it might >> actually cause silent data corruption. > > Somehow, if you're running a database on windoze, I doubt your data > integrity standards are that high. In any case I'd rather get a bleat > about "why is the server running in GMT" than "my database won't start". > The former will be a lot easier to narrow down. heh - except that we fail in that department - The only (not really useful hint) that pg logged was: "WARNUNG: could not query value for 'std' to identify Windows timezone: 2" which says nothing about "I failed to figure something sane out and so I have to fallback to GMT" (which is what the !WIN32 code path seems to be actually doing but not the WIN32 code). And even from the vendor perspective getting a support call on "uhm the database for your app is not starting what logs should I look at" seems better than "hmm we are now 2 weeks in production and just noticed that all the timestamps are off by a few hours how can we fix our data?". PostgreSQL is bundled with a lot of apps on windows these days so the enduser might not even aware of it (and look into the eventlog only to find a rather oddly phrased WARNING) unless it fails hard... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: [HACKERS] Missing win32 timezones Next: [HACKERS] pg_filedump strangeness |