Windows.
Recap: When running on a localized windows version, the timezone name
returned is also localized, and therefor does not match our lookup
table.
Solution: The registry contains both the name of the timezone in english
and the localized name. The patch adds code to scan the registry for the
localized name and gets the english name from that, and then rescans the
table.
I have tested this on a Swedish WinXP, and it works without problems.
The registry layout is the same in Win2k, but I haven't specifically
tested it. It's also the same on different languages but again only
Swedish is tested.
Magnus Hagander
it with previous prototype to suppress complaints from picky compilers,
per report from Scott Bailey. Also, remove substitute strerror
definition --- not needed, since we link this with libpgport.
machines, break tie scores by preferring shorter zone names over longer;
for names of equal length, prefer the alphabetically first name. This
yields for example 'EST5EDT' not 'America/New_York' for US eastern time.
On Windows, abandon the whole concept of inspecting the detailed behavior
of the system TZ library, because it doesn't bear inspection :-(. Instead
use a hardwired mapping table to select our zone name based on the
result of strftime %Z output. Windows code from Magnus Hagander.
timezone database for the system behavior we find ourselves in. Scan
backwards from current time and choose the zone that matches furthest
back. As per discussion a week or so back.
accurate matching of our time zone to the system's zone. This method is
able to distinguish Antarctica/Casey from Australia/Perth, as in Chris
K-L's recent example; and it is not materially slower than before, because
the extra checks generally don't get done against very many time zones.
It seems possible that with this test we'd be able to correctly identify
Windows timezones without looking at the timezone name, but I do not
have the ability to try it.
place of time_t, as per prior discussion. The behavior does not change
on machines without a 64-bit-int type, but on machines with one, which
is most, we are rid of the bizarre boundary behavior at the edges of
the 32-bit-time_t range (1901 and 2038). The system will now treat
times over the full supported timestamp range as being in your local
time zone. It may seem a little bizarre to consider that times in
4000 BC are PST or EST, but this is surely at least as reasonable as
propagating Gregorian calendar rules back that far.
I did not modify the format of the zic timezone database files, which
means that for the moment the system will not know about daylight-savings
periods outside the range 1901-2038. Given the way the files are set up,
it's not a simple decision like 'widen to 64 bits'; we have to actually
think about the range of years that need to be supported. We should
probably inquire what the plans of the upstream zic people are before
making any decisions of our own.
database, not just ones that we cons up POSIX names for. This looks
grim but it seems to take less than a second even on a relatively slow
machine, and since it only happens once during postmaster startup, that
seems acceptable.
of correctly identifying the system's daylight-savings transition rules.
This still begs the question of how to look through the zic database to
find a matching zone definition, but at least now we'll have some chance
of recognizing the match when we find it.
and should do now that we control our own destiny for timezone handling,
but this commit gets the bulk of the picayune diffs in place.
Magnus Hagander and Tom Lane.
