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
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 do
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
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 Jowett's idea of
-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
Dann Corbit [EMAIL PROTECTED
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
would actually be
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 sent to
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 actually
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 perfect match.
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 would
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 name that
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...)
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
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.
-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 zone
Oliver Jowett
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 in
16 matches
Mail list logo
