| Age | Commit message (Collapse) | Author |
|---|
|
systems. 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.
|
|
dates. Per 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.
|
|
|
|
systems, add verbose logging (at DEBUG4) to help identify why a given
time zone is not matched.
|
|
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.
|
|
names. Per report from Alvaro.
|
|
in postgresql.conf does the right thing. variable.c got this right, but
not pgtz.c ...
|
|
|
|
respect to doubly-starred comment blocks. Do some manual cleanup.
|
|
|
|
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.
|
|
used by zic anyway.
|
|
|
|
|
|
Create new get_* functions to access compiled-in paths and adjust if
relative installs are to be used.
Clean up substitute_libpath_macro() code.
|
|
|
|
|
|
|
|
|
|
Move timezone database to share/timezone.
|
|
|
|
|
|
#ifndef HAVE_SYMLINK
#define HAVE_SYMLINK 0
#endif
|
|
|
|
system headers.
Allow system to find timezone database by pasing pkglibdir into the
binary via a define.
|
|
|
|
Timezone code backend integration done by Magnus Hagander.
|
|
from our code.
|
|
|
|
|
