Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-22 Thread Oliver Jowett
Tom Lane wrote: Oliver Jowett <[EMAIL PROTECTED]> writes: It'd be nice to have a predictable timezone choice made when there's a tie. Perhaps we should order on timezone name in this case? The Antarctica zones would tend to win with such a rule, which is probably not what we want :-(. But certai

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-22 Thread Tom Lane
Oliver Jowett <[EMAIL PROTECTED]> writes: > It'd be nice to have a predictable timezone choice made when there's a > tie. Perhaps we should order on timezone name in this case? The Antarctica zones would tend to win with such a rule, which is probably not what we want :-(. But certainly we could

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-22 Thread Oliver Jowett
Tom Lane wrote: Oliver Jowett <[EMAIL PROTECTED]> writes: Also I'm a bit nervous about that hardcoded 2004 start date for the scan in pgtz.c -- that will presumably break if the timezone data files are updated for post-2004 changes without a corresponding change to the scan code. Actually, that

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-22 Thread Tom Lane
Oliver Jowett <[EMAIL PROTECTED]> writes: > Also I'm a bit nervous about that hardcoded 2004 start date for the scan > in pgtz.c -- that will presumably break if the timezone data files are > updated for post-2004 changes without a corresponding change to the scan > code. Actually, that was int

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-22 Thread Zeugswetter Andreas SB SD
> > DEBUG: TZ "Antarctica/McMurdo" scores 2534: at -442152000 > 1955-12-28 12:00:00 std versus 1955-12-29 00:00:00 std > > DEBUG: TZ "Antarctica/South_Pole" scores 2534: at > -442152000 1955-12-28 12:00:00 std versus 1955-12-29 00:00:00 std > > DEBUG: TZ "Pacific/Auckland" gets max score 2600

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-22 Thread Oliver Jowett
Oliver Jowett wrote: The only timezones that get positive scores during startup are: DEBUG: TZ "Antarctica/McMurdo" gets max score 2080 DEBUG: TZ "Antarctica/South_Pole" gets max score 2080 DEBUG: TZ "Pacific/Auckland" gets max score 2080 DEBUG: TZ "NZ" gets max score 2080 Either of "NZ" or "Pa

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-22 Thread Oliver Jowett
Tom Lane wrote: But in any case, I've committed code that implements Oliver's idea. Could folks take another swipe at it and see if it works well in their local zones? Also, it'd still be interesting to see if we could #ifdef out the matching on zone names for Windows and still get reasonable resu

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-21 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> Right. The problem we are actually faced with is to identify >> which of the zic timezones is the best match for the system's >> timezone setting. >> One of the issues is that it's not clear what "best" means... >> >> At the moment I like Oliver

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-16 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> At the moment I like Oliver Jowett's idea of defining "best" >> as "the one that matches furthest back". > Sounds reasonable to me. As long as a clear warning is put in the log > whenever something is picked that is not a perfect match, Define "pe

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-16 Thread Magnus Hagander
> >> I thought the issue under question was to find out what > the time zone > >> was. > > > Nope, we already had that. The issue is that the names are not the > > same as the one used in zic/unix, so there is nothing to match on. > > Right. The problem we are actually faced with is to identi

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-16 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> I thought the issue under question was to find out what the >> time zone was. > Nope, we already had that. The issue is that the names are not the same > as the one used in zic/unix, so there is nothing to match on. Right. The problem we are actu

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-16 Thread Magnus Hagander
> > Over-simplistic answers are not what we need here. The > data structure > > you quote cannot even tell what DST transition dates Windows thinks > > are in effect this year, let alone what it thinks the dates were in > > past years. > > Yes, there are other calls for that, obviously. I se

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-16 Thread Magnus Hagander
> >> It occurs to me that with a check this thorough, we might > be able to > >> finesse the problem on Windows with the system returning very > >> nonstandard timezone abbreviations. > > > It does *not* pick up my timezone. > > Drat. I assume from your domain name that Europe/Stockholm > wo

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-15 Thread Dann Corbit
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 15, 2004 10:03 PM > To: Dann Corbit > Cc: Oliver Jowett; Magnus Hagander; Hackers; > [EMAIL PROTECTED] > Subject: Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone > &g

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-15 Thread Tom Lane
"Dann Corbit" <[EMAIL PROTECTED]> writes: > All translations between UTC time and local time are based on the > following formula: > UTC = local time + bias Surely not. Or has Windows not heard of daylight-savings time? Or perhaps they have, but are not aware that the DST laws have changed often

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-15 Thread Dann Corbit
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Thursday, July 15, 2004 9:13 PM > To: Oliver Jowett > Cc: Magnus Hagander; Hackers; [EMAIL PROTECTED] > Subject: Re: [pgsql-hackers-win32] [HACKERS] Weird new time

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-15 Thread Tom Lane
Oliver Jowett <[EMAIL PROTECTED]> writes: > How about scanning backwards until you have <= 1 choice or decide to > give up? Hmm ... that really seems like not a bad idea. Scan all the available timezones, score each on how far back it goes before a mismatch, take the one that goes furthest back.

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-15 Thread Oliver Jowett
Tom Lane wrote: I thought about restricting the scope of the TZ testing to start in 1990 or so to avoid this, but that seems certain to fall foul of the other problem, which is distinguishing closely-related timezones (cf Chris K-L discovering that he lives in Antarctica, a few days back...) How ab

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-15 Thread Bruce Momjian
Tom Lane wrote: > I thought about restricting the scope of the TZ testing to start in 1990 > or so to avoid this, but that seems certain to fall foul of the other > problem, which is distinguishing closely-related timezones (cf Chris > K-L discovering that he lives in Antarctica, a few days back...

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-15 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> It occurs to me that with a check this thorough, we might be >> able to finesse the problem on Windows with the system >> returning very nonstandard timezone abbreviations. > It does *not* pick up my timezone. Drat. I assume from your domain nam

Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone

2004-07-15 Thread Magnus Hagander
>It occurs to me that with a check this thorough, we might be >able to finesse the problem on Windows with the system >returning very nonstandard timezone abbreviations. That is, >we might simply "#ifndef WIN32" the matching of zone names in >try_timezone(). However I do not know whether this