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
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
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
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
> > 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
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
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
"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
"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
> >> 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
"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
> > 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
> >> 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
> -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
"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
> -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
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.
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
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...
"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
>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
I wrote:
> I was initially thinking that probing a large number of test times
> would be expensive, but on second thought I don't see that it would
> be a problem. On nearly all the entries in the TZ database, we'd
> reject on the first or second probe time anyway; only very near
> matches such as
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Sat, Jul 10, 2004 at 12:40:21PM -0400, Tom Lane wrote:
>> Perhaps, rather than just probing a few selected years, we had better
>> check every year since 1970 ...
> What if we tell the user what the detected timezone is at some point,
> and tell them
On Sat, Jul 10, 2004 at 12:40:21PM -0400, Tom Lane wrote:
> Perhaps, rather than just probing a few selected years, we had better
> check every year since 1970 ...
What if we tell the user what the detected timezone is at some point,
and tell them that it's only a heuristic? So if somebody gets
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Attached is the startup log. I should point out that the Casey
> Antarctic base is in the Australian Antarctic Territory and it is in the
> same time zone as Perth, Western Australia for me:
Looking in the data files,
Zone Antarctica/Casey
You tell us ... what's your real timezone, and what do you get from
pushing up the log level to DEBUG4 during postmaster start?
OK, I have log level set to debug4 and australian_timezones set to true.
The system time zone is set to WST.
Attached is the startup log. I should point out that the
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> How come I default to Antartica in CVS?
You tell us ... what's your real timezone, and what do you get from
pushing up the log level to DEBUG4 during postmaster start?
regards, tom lane
---(end
How come I default to Antartica in CVS?
test=# show time zone;
TimeZone
--
Antarctica/Casey
(1 row)
test=#
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister Y
28 matches
Mail list logo
