rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/bin/initdb/findtimezone.c

1548 lines
44 KiB
C
Raw Normal View History

Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
/*-------------------------------------------------------------------------
*
* findtimezone.c
* Functions for determining the default timezone to use.
*
Update copyright for 2019 Backpatch-through: certain files through 9.4
2019-01-02 18:44:25 +01:00
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
*
* IDENTIFICATION
* src/bin/initdb/findtimezone.c
*
*-------------------------------------------------------------------------
*/
#include "postgres_fe.h"
#include <fcntl.h>
#include <sys/stat.h>
#include <time.h>
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
#include <unistd.h>
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
#include "pgtz.h"
/* Ideally this would be in a .h file, but it hardly seems worth the trouble */
extern const char *select_default_timezone(const char *share_path);
#ifndef SYSTEMTZDIR
static char tzdirpath[MAXPGPATH];
#endif
/*
* Return full pathname of timezone data directory
*
* In this file, tzdirpath is assumed to be set up by select_default_timezone.
*/
static const char *
pg_TZDIR(void)
{
#ifndef SYSTEMTZDIR
/* normal case: timezone stuff is under our share dir */
return tzdirpath;
#else
/* we're configured to use system's timezone database */
return SYSTEMTZDIR;
#endif
}
/*
* Given a timezone name, open() the timezone data file. Return the
* file descriptor if successful, -1 if not.
*
* This is simpler than the backend function of the same name because
* we assume that the input string has the correct case already, so there
* is no need for case-folding. (This is obviously true if we got the file
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* name from the filesystem to start with. The only other place it can come
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* from is the environment variable TZ, and there seems no need to allow
* case variation in that; other programs aren't likely to.)
*
* If "canonname" is not NULL, then on success the canonical spelling of the
* given name is stored there (the buffer must be > TZ_STRLEN_MAX bytes!).
* This is redundant but kept for compatibility with the backend code.
*/
int
pg_open_tzfile(const char *name, char *canonname)
{
char fullname[MAXPGPATH];
if (canonname)
strlcpy(canonname, name, TZ_STRLEN_MAX + 1);
Prevent potential overruns of fixed-size buffers. Coverity identified a number of places in which it couldn't prove that a string being copied into a fixed-size buffer would fit. We believe that most, perhaps all of these are in fact safe, or are copying data that is coming from a trusted source so that any overrun is not really a security issue. Nonetheless it seems prudent to forestall any risk by using strlcpy() and similar functions. Fixes by Peter Eisentraut and Jozef Mlich based on Coverity reports. In addition, fix a potential null-pointer-dereference crash in contrib/chkpass. The crypt(3) function is defined to return NULL on failure, but chkpass.c didn't check for that before using the result. The main practical case in which this could be an issue is if libc is configured to refuse to execute unapproved hashing algorithms (e.g., "FIPS mode"). This ideally should've been a separate commit, but since it touches code adjacent to one of the buffer overrun changes, I included it in this commit to avoid last-minute merge issues. This issue was reported by Honza Horak. Security: CVE-2014-0065 for buffer overruns, CVE-2014-0066 for crypt()
2014-02-17 17:20:21 +01:00
strlcpy(fullname, pg_TZDIR(), sizeof(fullname));
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
if (strlen(fullname) + 1 + strlen(name) >= MAXPGPATH)
return -1; /* not gonna fit */
strcat(fullname, "/");
strcat(fullname, name);
return open(fullname, O_RDONLY | PG_BINARY, 0);
}
/*
* Load a timezone definition.
* Does not verify that the timezone is acceptable!
*
* This corresponds to the backend's pg_tzset(), except that we only support
* one loaded timezone at a time.
*/
static pg_tz *
pg_load_tz(const char *name)
{
static pg_tz tz;
if (strlen(name) > TZ_STRLEN_MAX)
return NULL; /* not going to fit */
/*
* "GMT" is always sent to tzparse(); see comments for pg_tzset().
*/
if (strcmp(name, "GMT") == 0)
{
Sync tzload() and tzparse() APIs with IANA release tzcode2016c. This brings us a bit closer to matching upstream, but since it affects files outside src/timezone/, we might choose not to back-patch it. Hence keep it separate from the main update patch.
2016-03-28 23:19:29 +02:00
if (!tzparse(name, &tz.state, true))
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
/* This really, really should not happen ... */
return NULL;
}
}
Sync tzload() and tzparse() APIs with IANA release tzcode2016c. This brings us a bit closer to matching upstream, but since it affects files outside src/timezone/, we might choose not to back-patch it. Hence keep it separate from the main update patch.
2016-03-28 23:19:29 +02:00
else if (tzload(name, NULL, &tz.state, true) != 0)
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
Sync tzload() and tzparse() APIs with IANA release tzcode2016c. This brings us a bit closer to matching upstream, but since it affects files outside src/timezone/, we might choose not to back-patch it. Hence keep it separate from the main update patch.
2016-03-28 23:19:29 +02:00
if (name[0] == ':' || !tzparse(name, &tz.state, false))
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
return NULL; /* unknown timezone */
}
}
strcpy(tz.TZname, name);
return &tz;
}
/*
* The following block of code attempts to determine which timezone in our
* timezone database is the best match for the active system timezone.
*
* On most systems, we rely on trying to match the observable behavior of
* the C library's localtime() function. The database zone that matches
* furthest into the past is the one to use. Often there will be several
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
* zones with identical rankings (since the IANA database assigns multiple
Prefer timezone name "UTC" over alternative spellings. tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate zone with its own abbreviation. Unfortunately, our code for choosing a timezone in initdb has an arbitrary preference for names earlier in the alphabet, and so it would choose the spelling "UCT" over "UTC" when the system is running on a UTC zone. Commit 23bd3cec6 was backpatched in order to address this issue, but that code helps only when /etc/localtime exists as a symlink, and does nothing to help on systems where /etc/localtime is a copy of a zone file (as is the standard setup on FreeBSD and probably some other platforms too) or when /etc/localtime is simply absent (giving UTC as the default). Accordingly, add a preference for the spelling "UTC", such that if multiple zone names have equally good content matches, we prefer that name before applying the existing arbitrary rules. Also add a slightly lower preference for "Etc/UTC"; lower because that preserves the previous behaviour of choosing the shorter name, but letting us still choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does not (not common, but I've seen it happen). Backpatch all the way, because the tzdb change that sparked this issue is in those branches too.
2019-06-15 19:15:23 +02:00
* names to many zones). We break ties by first checking for "preferred"
* names (such as "UTC"), and then arbitrarily by preferring shorter, then
* alphabetically earlier zone names. (If we did not explicitly prefer
* "UTC", we would get the alias name "UCT" instead due to alphabetic
* ordering.)
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
*
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
* Many modern systems use the IANA database, so if we can determine the
* system's idea of which zone it is using and its behavior matches our zone
* of the same name, we can skip the rather-expensive search through all the
* zones in our database. This short-circuit path also ensures that we spell
* the zone name the same way the system setting does, even in the presence
* of multiple aliases for the same zone.
*
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* Win32's native knowledge about timezones appears to be too incomplete
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
* and too different from the IANA database for the above matching strategy
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* to be of any use. But there is just a limited number of timezones
* available, so we can rely on a handmade mapping table instead.
*/
#ifndef WIN32
#define T_DAY ((time_t) (60*60*24))
#define T_WEEK ((time_t) (60*60*24*7))
#define T_MONTH ((time_t) (60*60*24*31))
#define MAX_TEST_TIMES (52*100) /* 100 years */
struct tztry
{
int n_test_times;
time_t test_times[MAX_TEST_TIMES];
};
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
static bool check_system_link_file(const char *linkname, struct tztry *tt,
Phase 2 pgindent run for v12. Switch to 2.1 version of pg_bsd_indent. This formats multiline function declarations "correctly", that is with additional lines of parameter declarations indented to match where the first line's left parenthesis is. Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com
2019-05-22 19:04:48 +02:00
char *bestzonename);
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
static void scan_available_timezones(char *tzdir, char *tzdirsub,
Phase 2 pgindent run for v12. Switch to 2.1 version of pg_bsd_indent. This formats multiline function declarations "correctly", that is with additional lines of parameter declarations indented to match where the first line's left parenthesis is. Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com
2019-05-22 19:04:48 +02:00
struct tztry *tt,
int *bestscore, char *bestzonename);
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
/*
* Get GMT offset from a system struct tm
*/
static int
Initial pgindent run with pg_bsd_indent version 2.0. The new indent version includes numerous fixes thanks to Piotr Stefaniak. The main changes visible in this commit are: * Nicer formatting of function-pointer declarations. * No longer unexpectedly removes spaces in expressions using casts, sizeof, or offsetof. * No longer wants to add a space in "struct structname *varname", as well as some similar cases for const- or volatile-qualified pointers. * Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely. * Fixes bug where comments following declarations were sometimes placed with no space separating them from the code. * Fixes some odd decisions for comments following case labels. * Fixes some cases where comments following code were indented to less than the expected column 33. On the less good side, it now tends to put more whitespace around typedef names that are not listed in typedefs.list. This might encourage us to put more effort into typedef name collection; it's not really a bug in indent itself. There are more changes coming after this round, having to do with comment indentation and alignment of lines appearing within parentheses. I wanted to limit the size of the diffs to something that could be reviewed without one's eyes completely glazing over, so it seemed better to split up the changes as much as practical. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 20:39:04 +02:00
get_timezone_offset(struct tm *tm)
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
#if defined(HAVE_STRUCT_TM_TM_ZONE)
return tm->tm_gmtoff;
#elif defined(HAVE_INT_TIMEZONE)
return -TIMEZONE_GLOBAL;
#else
#error No way to determine TZ? Can this happen?
#endif
}
/*
* Convenience subroutine to convert y/m/d to time_t (NOT pg_time_t)
*/
static time_t
build_time_t(int year, int month, int day)
{
struct tm tm;
memset(&tm, 0, sizeof(tm));
tm.tm_mday = day;
tm.tm_mon = month - 1;
tm.tm_year = year - 1900;
return mktime(&tm);
}
/*
* Does a system tm value match one we computed ourselves?
*/
static bool
Initial pgindent run with pg_bsd_indent version 2.0. The new indent version includes numerous fixes thanks to Piotr Stefaniak. The main changes visible in this commit are: * Nicer formatting of function-pointer declarations. * No longer unexpectedly removes spaces in expressions using casts, sizeof, or offsetof. * No longer wants to add a space in "struct structname *varname", as well as some similar cases for const- or volatile-qualified pointers. * Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely. * Fixes bug where comments following declarations were sometimes placed with no space separating them from the code. * Fixes some odd decisions for comments following case labels. * Fixes some cases where comments following code were indented to less than the expected column 33. On the less good side, it now tends to put more whitespace around typedef names that are not listed in typedefs.list. This might encourage us to put more effort into typedef name collection; it's not really a bug in indent itself. There are more changes coming after this round, having to do with comment indentation and alignment of lines appearing within parentheses. I wanted to limit the size of the diffs to something that could be reviewed without one's eyes completely glazing over, so it seemed better to split up the changes as much as practical. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 20:39:04 +02:00
compare_tm(struct tm *s, struct pg_tm *p)
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
if (s->tm_sec != p->tm_sec ||
s->tm_min != p->tm_min ||
s->tm_hour != p->tm_hour ||
s->tm_mday != p->tm_mday ||
s->tm_mon != p->tm_mon ||
s->tm_year != p->tm_year ||
s->tm_wday != p->tm_wday ||
s->tm_yday != p->tm_yday ||
s->tm_isdst != p->tm_isdst)
return false;
return true;
}
/*
* See how well a specific timezone setting matches the system behavior
*
* We score a timezone setting according to the number of test times it
* matches. (The test times are ordered later-to-earlier, but this routine
* doesn't actually know that; it just scans until the first non-match.)
*
* We return -1 for a completely unusable setting; this is worse than the
* score of zero for a setting that works but matches not even the first
* test time.
*/
static int
Initial pgindent run with pg_bsd_indent version 2.0. The new indent version includes numerous fixes thanks to Piotr Stefaniak. The main changes visible in this commit are: * Nicer formatting of function-pointer declarations. * No longer unexpectedly removes spaces in expressions using casts, sizeof, or offsetof. * No longer wants to add a space in "struct structname *varname", as well as some similar cases for const- or volatile-qualified pointers. * Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely. * Fixes bug where comments following declarations were sometimes placed with no space separating them from the code. * Fixes some odd decisions for comments following case labels. * Fixes some cases where comments following code were indented to less than the expected column 33. On the less good side, it now tends to put more whitespace around typedef names that are not listed in typedefs.list. This might encourage us to put more effort into typedef name collection; it's not really a bug in indent itself. There are more changes coming after this round, having to do with comment indentation and alignment of lines appearing within parentheses. I wanted to limit the size of the diffs to something that could be reviewed without one's eyes completely glazing over, so it seemed better to split up the changes as much as practical. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 20:39:04 +02:00
score_timezone(const char *tzname, struct tztry *tt)
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
int i;
pg_time_t pgtt;
struct tm *systm;
struct pg_tm *pgtm;
char cbuf[TZ_STRLEN_MAX + 1];
pg_tz *tz;
/* Load timezone definition */
tz = pg_load_tz(tzname);
if (!tz)
return -1; /* unrecognized zone name */
/* Reject if leap seconds involved */
if (!pg_tz_acceptable(tz))
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "Reject TZ \"%s\": uses leap seconds\n", tzname);
#endif
return -1;
}
/* Check for match at all the test times */
for (i = 0; i < tt->n_test_times; i++)
{
pgtt = (pg_time_t) (tt->test_times[i]);
pgtm = pg_localtime(&pgtt, tz);
if (!pgtm)
return -1; /* probably shouldn't happen */
systm = localtime(&(tt->test_times[i]));
if (!systm)
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "TZ \"%s\" scores %d: at %ld %04d-%02d-%02d %02d:%02d:%02d %s, system had no data\n",
tzname, i, (long) pgtt,
pgtm->tm_year + 1900, pgtm->tm_mon + 1, pgtm->tm_mday,
pgtm->tm_hour, pgtm->tm_min, pgtm->tm_sec,
pgtm->tm_isdst ? "dst" : "std");
#endif
return i;
}
if (!compare_tm(systm, pgtm))
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "TZ \"%s\" scores %d: at %ld %04d-%02d-%02d %02d:%02d:%02d %s versus %04d-%02d-%02d %02d:%02d:%02d %s\n",
tzname, i, (long) pgtt,
pgtm->tm_year + 1900, pgtm->tm_mon + 1, pgtm->tm_mday,
pgtm->tm_hour, pgtm->tm_min, pgtm->tm_sec,
pgtm->tm_isdst ? "dst" : "std",
systm->tm_year + 1900, systm->tm_mon + 1, systm->tm_mday,
systm->tm_hour, systm->tm_min, systm->tm_sec,
systm->tm_isdst ? "dst" : "std");
#endif
return i;
}
if (systm->tm_isdst >= 0)
{
/* Check match of zone names, too */
if (pgtm->tm_zone == NULL)
return -1; /* probably shouldn't happen */
memset(cbuf, 0, sizeof(cbuf));
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
strftime(cbuf, sizeof(cbuf) - 1, "%Z", systm); /* zone abbr */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
if (strcmp(cbuf, pgtm->tm_zone) != 0)
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "TZ \"%s\" scores %d: at %ld \"%s\" versus \"%s\"\n",
tzname, i, (long) pgtt,
pgtm->tm_zone, cbuf);
#endif
return i;
}
}
}
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "TZ \"%s\" gets max score %d\n", tzname, i);
#endif
return i;
}
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
/*
* Test whether given zone name is a perfect match to localtime() behavior
*/
static bool
perfect_timezone_match(const char *tzname, struct tztry *tt)
{
return (score_timezone(tzname, tt) == tt->n_test_times);
}
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
/*
* Try to identify a timezone name (in our terminology) that best matches the
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
* observed behavior of the system localtime() function.
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
*/
static const char *
identify_system_timezone(void)
{
static char resultbuf[TZ_STRLEN_MAX + 1];
time_t tnow;
time_t t;
struct tztry tt;
struct tm *tm;
int thisyear;
int bestscore;
char tmptzdir[MAXPGPATH];
int std_ofs;
char std_zone_name[TZ_STRLEN_MAX + 1],
dst_zone_name[TZ_STRLEN_MAX + 1];
char cbuf[TZ_STRLEN_MAX + 1];
/* Initialize OS timezone library */
tzset();
/*
* Set up the list of dates to be probed to see how well our timezone
* matches the system zone. We first probe January and July of the
* current year; this serves to quickly eliminate the vast majority of the
* TZ database entries. If those dates match, we probe every week for 100
* years backwards from the current July. (Weekly resolution is good
* enough to identify DST transition rules, since everybody switches on
* Sundays.) This is sufficient to cover most of the Unix time_t range,
* and we don't want to look further than that since many systems won't
* have sane TZ behavior further back anyway. The further back the zone
* matches, the better we score it. This may seem like a rather random
* way of doing things, but experience has shown that system-supplied
* timezone definitions are likely to have DST behavior that is right for
* the recent past and not so accurate further back. Scoring in this way
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
* allows us to recognize zones that have some commonality with the IANA
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* database, without insisting on exact match. (Note: we probe Thursdays,
* not Sundays, to avoid triggering DST-transition bugs in localtime
* itself.)
*/
tnow = time(NULL);
tm = localtime(&tnow);
if (!tm)
return NULL; /* give up if localtime is broken... */
thisyear = tm->tm_year + 1900;
t = build_time_t(thisyear, 1, 15);
/*
* Round back to GMT midnight Thursday. This depends on the knowledge
* that the time_t origin is Thu Jan 01 1970. (With a different origin
* we'd be probing some other day of the week, but it wouldn't matter
* anyway unless localtime() had DST-transition bugs.)
*/
t -= (t % T_WEEK);
tt.n_test_times = 0;
tt.test_times[tt.n_test_times++] = t;
t = build_time_t(thisyear, 7, 15);
t -= (t % T_WEEK);
tt.test_times[tt.n_test_times++] = t;
while (tt.n_test_times < MAX_TEST_TIMES)
{
t -= T_WEEK;
tt.test_times[tt.n_test_times++] = t;
}
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
/*
* Try to avoid the brute-force search by seeing if we can recognize the
* system's timezone setting directly.
*
* Currently we just check /etc/localtime; there are other conventions for
* this, but that seems to be the only one used on enough platforms to be
* worth troubling over.
*/
if (check_system_link_file("/etc/localtime", &tt, resultbuf))
return resultbuf;
/* No luck, so search for the best-matching timezone file */
Prevent potential overruns of fixed-size buffers. Coverity identified a number of places in which it couldn't prove that a string being copied into a fixed-size buffer would fit. We believe that most, perhaps all of these are in fact safe, or are copying data that is coming from a trusted source so that any overrun is not really a security issue. Nonetheless it seems prudent to forestall any risk by using strlcpy() and similar functions. Fixes by Peter Eisentraut and Jozef Mlich based on Coverity reports. In addition, fix a potential null-pointer-dereference crash in contrib/chkpass. The crypt(3) function is defined to return NULL on failure, but chkpass.c didn't check for that before using the result. The main practical case in which this could be an issue is if libc is configured to refuse to execute unapproved hashing algorithms (e.g., "FIPS mode"). This ideally should've been a separate commit, but since it touches code adjacent to one of the buffer overrun changes, I included it in this commit to avoid last-minute merge issues. This issue was reported by Honza Horak. Security: CVE-2014-0065 for buffer overruns, CVE-2014-0066 for crypt()
2014-02-17 17:20:21 +01:00
strlcpy(tmptzdir, pg_TZDIR(), sizeof(tmptzdir));
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
bestscore = -1;
resultbuf[0] = '\0';
scan_available_timezones(tmptzdir, tmptzdir + strlen(tmptzdir) + 1,
&tt,
&bestscore, resultbuf);
if (bestscore > 0)
{
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
/* Ignore IANA's rather silly "Factory" zone; use GMT instead */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
if (strcmp(resultbuf, "Factory") == 0)
return NULL;
return resultbuf;
}
/*
* Couldn't find a match in the database, so next we try constructed zone
* names (like "PST8PDT").
*
* First we need to determine the names of the local standard and daylight
* zones. The idea here is to scan forward from today until we have seen
* both zones, if both are in use.
*/
memset(std_zone_name, 0, sizeof(std_zone_name));
memset(dst_zone_name, 0, sizeof(dst_zone_name));
std_ofs = 0;
tnow = time(NULL);
/*
* Round back to a GMT midnight so results don't depend on local time of
* day
*/
tnow -= (tnow % T_DAY);
/*
* We have to look a little further ahead than one year, in case today is
* just past a DST boundary that falls earlier in the year than the next
* similar boundary. Arbitrarily scan up to 14 months.
*/
for (t = tnow; t <= tnow + T_MONTH * 14; t += T_MONTH)
{
tm = localtime(&t);
if (!tm)
continue;
if (tm->tm_isdst < 0)
continue;
if (tm->tm_isdst == 0 && std_zone_name[0] == '\0')
{
/* found STD zone */
memset(cbuf, 0, sizeof(cbuf));
strftime(cbuf, sizeof(cbuf) - 1, "%Z", tm); /* zone abbr */
strcpy(std_zone_name, cbuf);
std_ofs = get_timezone_offset(tm);
}
if (tm->tm_isdst > 0 && dst_zone_name[0] == '\0')
{
/* found DST zone */
memset(cbuf, 0, sizeof(cbuf));
strftime(cbuf, sizeof(cbuf) - 1, "%Z", tm); /* zone abbr */
strcpy(dst_zone_name, cbuf);
}
/* Done if found both */
if (std_zone_name[0] && dst_zone_name[0])
break;
}
/* We should have found a STD zone name by now... */
if (std_zone_name[0] == '\0')
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "could not determine system time zone\n");
#endif
return NULL; /* go to GMT */
}
/* If we found DST then try STD<ofs>DST */
if (dst_zone_name[0] != '\0')
{
snprintf(resultbuf, sizeof(resultbuf), "%s%d%s",
std_zone_name, -std_ofs / 3600, dst_zone_name);
if (score_timezone(resultbuf, &tt) > 0)
return resultbuf;
}
/* Try just the STD timezone (works for GMT at least) */
strcpy(resultbuf, std_zone_name);
if (score_timezone(resultbuf, &tt) > 0)
return resultbuf;
/* Try STD<ofs> */
snprintf(resultbuf, sizeof(resultbuf), "%s%d",
std_zone_name, -std_ofs / 3600);
if (score_timezone(resultbuf, &tt) > 0)
return resultbuf;
/*
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* Did not find the timezone. Fallback to use a GMT zone. Note that the
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
* IANA timezone database names the GMT-offset zones in POSIX style: plus
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* is west of Greenwich. It's unfortunate that this is opposite of SQL
* conventions. Should we therefore change the names? Probably not...
*/
snprintf(resultbuf, sizeof(resultbuf), "Etc/GMT%s%d",
(-std_ofs > 0) ? "+" : "", -std_ofs / 3600);
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "could not recognize system time zone, using \"%s\"\n",
resultbuf);
#endif
return resultbuf;
}
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
/*
* Examine a system-provided symlink file to see if it tells us the timezone.
*
* Unfortunately, there is little standardization of how the system default
* timezone is determined in the absence of a TZ environment setting.
* But a common strategy is to create a symlink at a well-known place.
* If "linkname" identifies a readable symlink, and the tail of its contents
* matches a zone name we know, and the actual behavior of localtime() agrees
* with what we think that zone means, then we may use that zone name.
*
* We insist on a perfect behavioral match, which might not happen if the
* system has a different IANA database version than we do; but in that case
* it seems best to fall back to the brute-force search.
*
* linkname is the symlink file location to probe.
*
* tt tells about the system timezone behavior we need to match.
*
* If we successfully identify a zone name, store it in *bestzonename and
* return true; else return false. bestzonename must be a buffer of length
* TZ_STRLEN_MAX + 1.
*/
static bool
check_system_link_file(const char *linkname, struct tztry *tt,
char *bestzonename)
{
#ifdef HAVE_READLINK
char link_target[MAXPGPATH];
int len;
const char *cur_name;
/*
* Try to read the symlink. If not there, not a symlink, etc etc, just
* quietly fail; the precise reason needn't concern us.
*/
len = readlink(linkname, link_target, sizeof(link_target));
if (len < 0 || len >= sizeof(link_target))
return false;
link_target[len] = '\0';
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "symbolic link \"%s\" contains \"%s\"\n",
linkname, link_target);
#endif
/*
* The symlink is probably of the form "/path/to/zones/zone/name", or
* possibly it is a relative path. Nobody puts their zone DB directly in
* the root directory, so we can definitely skip the first component; but
* after that it's trial-and-error to identify which path component begins
* the zone name.
*/
cur_name = link_target;
while (*cur_name)
{
/* Advance to next segment of path */
cur_name = strchr(cur_name + 1, '/');
if (cur_name == NULL)
break;
/* If there are consecutive slashes, skip all, as the kernel would */
do
{
cur_name++;
} while (*cur_name == '/');
/*
* Test remainder of path to see if it is a matching zone name.
* Relative paths might contain ".."; we needn't bother testing if the
* first component is that. Also defend against overlength names.
*/
if (*cur_name && *cur_name != '.' &&
strlen(cur_name) <= TZ_STRLEN_MAX &&
perfect_timezone_match(cur_name, tt))
{
/* Success! */
strcpy(bestzonename, cur_name);
return true;
}
}
/* Couldn't extract a matching zone name */
return false;
#else
/* No symlinks? Forget it */
return false;
#endif
}
Prefer timezone name "UTC" over alternative spellings. tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate zone with its own abbreviation. Unfortunately, our code for choosing a timezone in initdb has an arbitrary preference for names earlier in the alphabet, and so it would choose the spelling "UCT" over "UTC" when the system is running on a UTC zone. Commit 23bd3cec6 was backpatched in order to address this issue, but that code helps only when /etc/localtime exists as a symlink, and does nothing to help on systems where /etc/localtime is a copy of a zone file (as is the standard setup on FreeBSD and probably some other platforms too) or when /etc/localtime is simply absent (giving UTC as the default). Accordingly, add a preference for the spelling "UTC", such that if multiple zone names have equally good content matches, we prefer that name before applying the existing arbitrary rules. Also add a slightly lower preference for "Etc/UTC"; lower because that preserves the previous behaviour of choosing the shorter name, but letting us still choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does not (not common, but I've seen it happen). Backpatch all the way, because the tzdb change that sparked this issue is in those branches too.
2019-06-15 19:15:23 +02:00
/*
* Given a timezone name, determine whether it should be preferred over other
* names which are equally good matches. The output is arbitrary but we will
Avoid choosing "localtime" or "posixrules" as TimeZone during initdb. Some platforms create a file named "localtime" in the system timezone directory, making it a copy or link to the active time zone file. If Postgres is built with --with-system-tzdata, initdb will see that file as an exact match to localtime(3)'s behavior, and it may decide that "localtime" is the most preferred spelling of the active zone. That's a very bad choice though, because it's neither informative, nor portable, nor stable if someone changes the system timezone setting. Extend the preference logic added by commit e3846a00c so that we will prefer any other zone file that matches localtime's behavior over "localtime". On the same logic, also discriminate against "posixrules", which is another not-really-a-zone file that is often present in the timezone directory. (Since we install "posixrules" but not "localtime", this change can affect the behavior of Postgres with or without --with-system-tzdata.) Note that this change doesn't prevent anyone from choosing these pseudo-zones if they really want to (i.e., by setting TZ for initdb, or modifying the timezone GUC later on). It just prevents initdb from preferring these zone names when there are multiple matches to localtime's behavior. Since we generally prefer to keep timezone-related behavior the same in all branches, and since this is arguably a bug fix, back-patch to all supported branches. Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com Discussion: https://postgr.es/m/27991.1560984458@sss.pgh.pa.us
2019-07-26 18:45:32 +02:00
* use 0 for "neutral" default preference; larger values are more preferred.
Prefer timezone name "UTC" over alternative spellings. tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate zone with its own abbreviation. Unfortunately, our code for choosing a timezone in initdb has an arbitrary preference for names earlier in the alphabet, and so it would choose the spelling "UCT" over "UTC" when the system is running on a UTC zone. Commit 23bd3cec6 was backpatched in order to address this issue, but that code helps only when /etc/localtime exists as a symlink, and does nothing to help on systems where /etc/localtime is a copy of a zone file (as is the standard setup on FreeBSD and probably some other platforms too) or when /etc/localtime is simply absent (giving UTC as the default). Accordingly, add a preference for the spelling "UTC", such that if multiple zone names have equally good content matches, we prefer that name before applying the existing arbitrary rules. Also add a slightly lower preference for "Etc/UTC"; lower because that preserves the previous behaviour of choosing the shorter name, but letting us still choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does not (not common, but I've seen it happen). Backpatch all the way, because the tzdb change that sparked this issue is in those branches too.
2019-06-15 19:15:23 +02:00
*/
static int
zone_name_pref(const char *zonename)
{
Avoid choosing "localtime" or "posixrules" as TimeZone during initdb. Some platforms create a file named "localtime" in the system timezone directory, making it a copy or link to the active time zone file. If Postgres is built with --with-system-tzdata, initdb will see that file as an exact match to localtime(3)'s behavior, and it may decide that "localtime" is the most preferred spelling of the active zone. That's a very bad choice though, because it's neither informative, nor portable, nor stable if someone changes the system timezone setting. Extend the preference logic added by commit e3846a00c so that we will prefer any other zone file that matches localtime's behavior over "localtime". On the same logic, also discriminate against "posixrules", which is another not-really-a-zone file that is often present in the timezone directory. (Since we install "posixrules" but not "localtime", this change can affect the behavior of Postgres with or without --with-system-tzdata.) Note that this change doesn't prevent anyone from choosing these pseudo-zones if they really want to (i.e., by setting TZ for initdb, or modifying the timezone GUC later on). It just prevents initdb from preferring these zone names when there are multiple matches to localtime's behavior. Since we generally prefer to keep timezone-related behavior the same in all branches, and since this is arguably a bug fix, back-patch to all supported branches. Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com Discussion: https://postgr.es/m/27991.1560984458@sss.pgh.pa.us
2019-07-26 18:45:32 +02:00
/*
* Prefer UTC over alternatives such as UCT. Also prefer Etc/UTC over
* Etc/UCT; but UTC is preferred to Etc/UTC.
*/
Prefer timezone name "UTC" over alternative spellings. tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate zone with its own abbreviation. Unfortunately, our code for choosing a timezone in initdb has an arbitrary preference for names earlier in the alphabet, and so it would choose the spelling "UCT" over "UTC" when the system is running on a UTC zone. Commit 23bd3cec6 was backpatched in order to address this issue, but that code helps only when /etc/localtime exists as a symlink, and does nothing to help on systems where /etc/localtime is a copy of a zone file (as is the standard setup on FreeBSD and probably some other platforms too) or when /etc/localtime is simply absent (giving UTC as the default). Accordingly, add a preference for the spelling "UTC", such that if multiple zone names have equally good content matches, we prefer that name before applying the existing arbitrary rules. Also add a slightly lower preference for "Etc/UTC"; lower because that preserves the previous behaviour of choosing the shorter name, but letting us still choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does not (not common, but I've seen it happen). Backpatch all the way, because the tzdb change that sparked this issue is in those branches too.
2019-06-15 19:15:23 +02:00
if (strcmp(zonename, "UTC") == 0)
return 50;
if (strcmp(zonename, "Etc/UTC") == 0)
return 40;
Avoid choosing "localtime" or "posixrules" as TimeZone during initdb. Some platforms create a file named "localtime" in the system timezone directory, making it a copy or link to the active time zone file. If Postgres is built with --with-system-tzdata, initdb will see that file as an exact match to localtime(3)'s behavior, and it may decide that "localtime" is the most preferred spelling of the active zone. That's a very bad choice though, because it's neither informative, nor portable, nor stable if someone changes the system timezone setting. Extend the preference logic added by commit e3846a00c so that we will prefer any other zone file that matches localtime's behavior over "localtime". On the same logic, also discriminate against "posixrules", which is another not-really-a-zone file that is often present in the timezone directory. (Since we install "posixrules" but not "localtime", this change can affect the behavior of Postgres with or without --with-system-tzdata.) Note that this change doesn't prevent anyone from choosing these pseudo-zones if they really want to (i.e., by setting TZ for initdb, or modifying the timezone GUC later on). It just prevents initdb from preferring these zone names when there are multiple matches to localtime's behavior. Since we generally prefer to keep timezone-related behavior the same in all branches, and since this is arguably a bug fix, back-patch to all supported branches. Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com Discussion: https://postgr.es/m/27991.1560984458@sss.pgh.pa.us
2019-07-26 18:45:32 +02:00
/*
* We don't want to pick "localtime" or "posixrules", unless we can find
* no other name for the prevailing zone. Those aren't real zone names.
*/
if (strcmp(zonename, "localtime") == 0 ||
strcmp(zonename, "posixrules") == 0)
return -50;
Prefer timezone name "UTC" over alternative spellings. tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate zone with its own abbreviation. Unfortunately, our code for choosing a timezone in initdb has an arbitrary preference for names earlier in the alphabet, and so it would choose the spelling "UCT" over "UTC" when the system is running on a UTC zone. Commit 23bd3cec6 was backpatched in order to address this issue, but that code helps only when /etc/localtime exists as a symlink, and does nothing to help on systems where /etc/localtime is a copy of a zone file (as is the standard setup on FreeBSD and probably some other platforms too) or when /etc/localtime is simply absent (giving UTC as the default). Accordingly, add a preference for the spelling "UTC", such that if multiple zone names have equally good content matches, we prefer that name before applying the existing arbitrary rules. Also add a slightly lower preference for "Etc/UTC"; lower because that preserves the previous behaviour of choosing the shorter name, but letting us still choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does not (not common, but I've seen it happen). Backpatch all the way, because the tzdb change that sparked this issue is in those branches too.
2019-06-15 19:15:23 +02:00
return 0;
}
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
/*
* Recursively scan the timezone database looking for the best match to
* the system timezone behavior.
*
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* tzdir points to a buffer of size MAXPGPATH. On entry, it holds the
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* pathname of a directory containing TZ files. We internally modify it
* to hold pathnames of sub-directories and files, but must restore it
* to its original contents before exit.
*
* tzdirsub points to the part of tzdir that represents the subfile name
* (ie, tzdir + the original directory name length, plus one for the
* first added '/').
*
* tt tells about the system timezone behavior we need to match.
*
* *bestscore and *bestzonename on entry hold the best score found so far
* and the name of the best zone. We overwrite them if we find a better
* score. bestzonename must be a buffer of length TZ_STRLEN_MAX + 1.
*/
static void
Initial pgindent run with pg_bsd_indent version 2.0. The new indent version includes numerous fixes thanks to Piotr Stefaniak. The main changes visible in this commit are: * Nicer formatting of function-pointer declarations. * No longer unexpectedly removes spaces in expressions using casts, sizeof, or offsetof. * No longer wants to add a space in "struct structname *varname", as well as some similar cases for const- or volatile-qualified pointers. * Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely. * Fixes bug where comments following declarations were sometimes placed with no space separating them from the code. * Fixes some odd decisions for comments following case labels. * Fixes some cases where comments following code were indented to less than the expected column 33. On the less good side, it now tends to put more whitespace around typedef names that are not listed in typedefs.list. This might encourage us to put more effort into typedef name collection; it's not really a bug in indent itself. There are more changes coming after this round, having to do with comment indentation and alignment of lines appearing within parentheses. I wanted to limit the size of the diffs to something that could be reviewed without one's eyes completely glazing over, so it seemed better to split up the changes as much as practical. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 20:39:04 +02:00
scan_available_timezones(char *tzdir, char *tzdirsub, struct tztry *tt,
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
int *bestscore, char *bestzonename)
{
int tzdir_orig_len = strlen(tzdir);
char **names;
char **namep;
names = pgfnames(tzdir);
if (!names)
return;
for (namep = names; *namep; namep++)
{
char *name = *namep;
struct stat statbuf;
/* Ignore . and .., plus any other "hidden" files */
if (name[0] == '.')
continue;
snprintf(tzdir + tzdir_orig_len, MAXPGPATH - tzdir_orig_len,
"/%s", name);
if (stat(tzdir, &statbuf) != 0)
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "could not stat \"%s\": %s\n",
tzdir, strerror(errno));
#endif
tzdir[tzdir_orig_len] = '\0';
continue;
}
if (S_ISDIR(statbuf.st_mode))
{
/* Recurse into subdirectory */
scan_available_timezones(tzdir, tzdirsub, tt,
bestscore, bestzonename);
}
else
{
/* Load and test this file */
int score = score_timezone(tzdirsub, tt);
if (score > *bestscore)
{
*bestscore = score;
strlcpy(bestzonename, tzdirsub, TZ_STRLEN_MAX + 1);
}
else if (score == *bestscore)
{
/* Consider how to break a tie */
pgindent run prior to branching v12. pgperltidy and reformat-dat-files too, though the latter didn't find anything to change.
2019-07-01 18:37:52 +02:00
int namepref = (zone_name_pref(tzdirsub) -
zone_name_pref(bestzonename));
Prefer timezone name "UTC" over alternative spellings. tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate zone with its own abbreviation. Unfortunately, our code for choosing a timezone in initdb has an arbitrary preference for names earlier in the alphabet, and so it would choose the spelling "UCT" over "UTC" when the system is running on a UTC zone. Commit 23bd3cec6 was backpatched in order to address this issue, but that code helps only when /etc/localtime exists as a symlink, and does nothing to help on systems where /etc/localtime is a copy of a zone file (as is the standard setup on FreeBSD and probably some other platforms too) or when /etc/localtime is simply absent (giving UTC as the default). Accordingly, add a preference for the spelling "UTC", such that if multiple zone names have equally good content matches, we prefer that name before applying the existing arbitrary rules. Also add a slightly lower preference for "Etc/UTC"; lower because that preserves the previous behaviour of choosing the shorter name, but letting us still choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does not (not common, but I've seen it happen). Backpatch all the way, because the tzdb change that sparked this issue is in those branches too.
2019-06-15 19:15:23 +02:00
if (namepref > 0 ||
(namepref == 0 &&
(strlen(tzdirsub) < strlen(bestzonename) ||
(strlen(tzdirsub) == strlen(bestzonename) &&
strcmp(tzdirsub, bestzonename) < 0))))
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
strlcpy(bestzonename, tzdirsub, TZ_STRLEN_MAX + 1);
}
}
/* Restore tzdir */
tzdir[tzdir_orig_len] = '\0';
}
pgfnames_cleanup(names);
}
#else /* WIN32 */
static const struct
{
const char *stdname; /* Windows name of standard timezone */
const char *dstname; /* Windows name of daylight timezone */
const char *pgtzname; /* Name of pgsql timezone to map to */
Initial pgindent run with pg_bsd_indent version 2.0. The new indent version includes numerous fixes thanks to Piotr Stefaniak. The main changes visible in this commit are: * Nicer formatting of function-pointer declarations. * No longer unexpectedly removes spaces in expressions using casts, sizeof, or offsetof. * No longer wants to add a space in "struct structname *varname", as well as some similar cases for const- or volatile-qualified pointers. * Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely. * Fixes bug where comments following declarations were sometimes placed with no space separating them from the code. * Fixes some odd decisions for comments following case labels. * Fixes some cases where comments following code were indented to less than the expected column 33. On the less good side, it now tends to put more whitespace around typedef names that are not listed in typedefs.list. This might encourage us to put more effort into typedef name collection; it's not really a bug in indent itself. There are more changes coming after this round, having to do with comment indentation and alignment of lines appearing within parentheses. I wanted to limit the size of the diffs to something that could be reviewed without one's eyes completely glazing over, so it seemed better to split up the changes as much as practical. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 20:39:04 +02:00
} win32_tzmap[] =
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
/*
* This list was built from the contents of the registry at
* HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
* Zones on Windows 10 and Windows 7.
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
*
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us
2018-09-13 18:36:21 +02:00
* The zones have been matched to IANA timezones by looking at the cities
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* listed in the win32 display name (in the comment here) in most cases.
*/
{
"Afghanistan Standard Time", "Afghanistan Daylight Time",
"Asia/Kabul"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+04:30) Kabul */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Alaskan Standard Time", "Alaskan Daylight Time",
"US/Alaska"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-09:00) Alaska */
{
"Aleutian Standard Time", "Aleutian Daylight Time",
"US/Aleutan"
}, /* (UTC-10:00) Aleutian Islands */
{
"Altai Standard Time", "Altai Daylight Time",
"Asia/Barnaul"
}, /* (UTC+07:00) Barnaul, Gorno-Altaysk */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Arab Standard Time", "Arab Daylight Time",
"Asia/Kuwait"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+03:00) Kuwait, Riyadh */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Arabian Standard Time", "Arabian Daylight Time",
"Asia/Muscat"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+04:00) Abu Dhabi, Muscat */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Arabic Standard Time", "Arabic Daylight Time",
"Asia/Baghdad"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+03:00) Baghdad */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Argentina Standard Time", "Argentina Daylight Time",
"America/Buenos_Aires"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-03:00) City of Buenos Aires */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Armenian Standard Time", "Armenian Daylight Time",
"Asia/Yerevan"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+04:00) Baku, Tbilisi, Yerevan */
{
"Astrakhan Standard Time", "Astrakhan Daylight Time",
"Europe/Astrakhan"
}, /* (UTC+04:00) Astrakhan, Ulyanovsk */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Atlantic Standard Time", "Atlantic Daylight Time",
"Canada/Atlantic"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-04:00) Atlantic Time (Canada) */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"AUS Central Standard Time", "AUS Central Daylight Time",
"Australia/Darwin"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+09:30) Darwin */
{
"Aus Central W. Standard Time", "Aus Central W. Daylight Time",
"Australia/Eucla"
}, /* (UTC+08:45) Eucla */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"AUS Eastern Standard Time", "AUS Eastern Daylight Time",
"Australia/Canberra"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+10:00) Canberra, Melbourne, Sydney */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Azerbaijan Standard Time", "Azerbaijan Daylight Time",
"Asia/Baku"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+04:00) Baku */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Azores Standard Time", "Azores Daylight Time",
"Atlantic/Azores"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-01:00) Azores */
{
"Bahia Standard Time", "Bahia Daylight Time",
"America/Salvador"
}, /* (UTC-03:00) Salvador */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Bangladesh Standard Time", "Bangladesh Daylight Time",
"Asia/Dhaka"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+06:00) Dhaka */
{
"Bougainville Standard Time", "Bougainville Daylight Time",
"Pacific/Bougainville"
}, /* (UTC+11:00) Bougainville Island */
{
"Belarus Standard Time", "Belarus Daylight Time",
"Europe/Minsk"
}, /* (UTC+03:00) Minsk */
{
"Cabo Verde Standard Time", "Cabo Verde Daylight Time",
"Atlantic/Cape_Verde"
}, /* (UTC-01:00) Cabo Verde Is. */
{
"Chatham Islands Standard Time", "Chatham Islands Daylight Time",
"Pacific/Chatham"
}, /* (UTC+12:45) Chatham Islands */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Canada Central Standard Time", "Canada Central Daylight Time",
"Canada/Saskatchewan"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-06:00) Saskatchewan */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Cape Verde Standard Time", "Cape Verde Daylight Time",
"Atlantic/Cape_Verde"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-01:00) Cape Verde Is. */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Caucasus Standard Time", "Caucasus Daylight Time",
"Asia/Baku"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+04:00) Yerevan */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Cen. Australia Standard Time", "Cen. Australia Daylight Time",
"Australia/Adelaide"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+09:30) Adelaide */
Fix our mapping of Windows timezones for Central America. We were mapping "Central America Standard Time" to "CST6CDT", which seems entirely wrong, because according to the Olson timezone database noplace in Central America observes daylight savings time on any regular basis --- and certainly not according to the USA DST rules that are implied by "CST6CDT". (Mexico is an exception, but they can be disregarded since they have a separate timezone name in Windows.) So, map this zone name to plain "CST6", which will provide a fixed UTC offset. As written, this patch will also result in mapping "Central America Daylight Time" to CST6. I considered hacking things so that would still map to CST6CDT, but it seems it would confuse win32tzlist.pl to put those two names in separate entries. Since there's little evidence that any such zone name is used in the wild, much less that CST6CDT would be a good match for it, I'm not too worried about what we do with it. Per complaint from Pratik Chirania.
2011-09-24 04:07:52 +02:00
/* Central America (other than Mexico) generally does not observe DST */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Central America Standard Time", "Central America Daylight Time",
Fix our mapping of Windows timezones for Central America. We were mapping "Central America Standard Time" to "CST6CDT", which seems entirely wrong, because according to the Olson timezone database noplace in Central America observes daylight savings time on any regular basis --- and certainly not according to the USA DST rules that are implied by "CST6CDT". (Mexico is an exception, but they can be disregarded since they have a separate timezone name in Windows.) So, map this zone name to plain "CST6", which will provide a fixed UTC offset. As written, this patch will also result in mapping "Central America Daylight Time" to CST6. I considered hacking things so that would still map to CST6CDT, but it seems it would confuse win32tzlist.pl to put those two names in separate entries. Since there's little evidence that any such zone name is used in the wild, much less that CST6CDT would be a good match for it, I'm not too worried about what we do with it. Per complaint from Pratik Chirania.
2011-09-24 04:07:52 +02:00
"CST6"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-06:00) Central America */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Central Asia Standard Time", "Central Asia Daylight Time",
"Asia/Dhaka"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+06:00) Astana */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Central Brazilian Standard Time", "Central Brazilian Daylight Time",
"America/Cuiaba"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-04:00) Cuiaba */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Central Europe Standard Time", "Central Europe Daylight Time",
"Europe/Belgrade"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+01:00) Belgrade, Bratislava, Budapest,
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* Ljubljana, Prague */
{
"Central European Standard Time", "Central European Daylight Time",
"Europe/Sarajevo"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+01:00) Sarajevo, Skopje, Warsaw,
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* Zagreb */
{
"Central Pacific Standard Time", "Central Pacific Daylight Time",
"Pacific/Noumea"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+11:00) Solomon Is., New Caledonia */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Central Standard Time", "Central Daylight Time",
"US/Central"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-06:00) Central Time (US & Canada) */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Central Standard Time (Mexico)", "Central Daylight Time (Mexico)",
"America/Mexico_City"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-06:00) Guadalajara, Mexico City,
* Monterrey */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"China Standard Time", "China Daylight Time",
"Asia/Hong_Kong"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+08:00) Beijing, Chongqing, Hong Kong,
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* Urumqi */
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
{
"Cuba Standard Time", "Cuba Daylight Time",
"America/Havana"
}, /* (UTC-05:00) Havana */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Dateline Standard Time", "Dateline Daylight Time",
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
"Etc/UTC+12"
}, /* (UTC-12:00) International Date Line West */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"E. Africa Standard Time", "E. Africa Daylight Time",
"Africa/Nairobi"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+03:00) Nairobi */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"E. Australia Standard Time", "E. Australia Daylight Time",
"Australia/Brisbane"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+10:00) Brisbane */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"E. Europe Standard Time", "E. Europe Daylight Time",
"Europe/Bucharest"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+02:00) E. Europe */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"E. South America Standard Time", "E. South America Daylight Time",
"America/Araguaina"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-03:00) Brasilia */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Eastern Standard Time", "Eastern Daylight Time",
"US/Eastern"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-05:00) Eastern Time (US & Canada) */
{
"Eastern Standard Time (Mexico)", "Eastern Daylight Time (Mexico)",
"America/Mexico_City"
}, /* (UTC-05:00) Chetumal */
{
"Easter Island Standard Time", "Easter Island Daylight Time",
"Pacific/Easter"
}, /* (UTC-06:00) Easter Island */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Egypt Standard Time", "Egypt Daylight Time",
"Africa/Cairo"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+02:00) Cairo */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
"Ekaterinburg Standard Time (RTZ 4)", "Ekaterinburg Daylight Time",
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
"Asia/Yekaterinburg"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+05:00) Ekaterinburg */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Fiji Standard Time", "Fiji Daylight Time",
"Pacific/Fiji"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+12:00) Fiji */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"FLE Standard Time", "FLE Daylight Time",
"Europe/Helsinki"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+02:00) Helsinki, Kyiv, Riga, Sofia,
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* Tallinn, Vilnius */
{
"Georgian Standard Time", "Georgian Daylight Time",
"Asia/Tbilisi"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+04:00) Tbilisi */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"GMT Standard Time", "GMT Daylight Time",
"Europe/London"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC) Dublin, Edinburgh, Lisbon, London */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Greenland Standard Time", "Greenland Daylight Time",
"America/Godthab"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-03:00) Greenland */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Greenwich Standard Time", "Greenwich Daylight Time",
"Africa/Casablanca"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC) Monrovia, Reykjavik */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"GTB Standard Time", "GTB Daylight Time",
"Europe/Athens"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+02:00) Athens, Bucharest */
{
"Haiti Standard Time", "Haiti Daylight Time",
"US/Eastern"
}, /* (UTC-05:00) Haiti */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Hawaiian Standard Time", "Hawaiian Daylight Time",
"US/Hawaii"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-10:00) Hawaii */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"India Standard Time", "India Daylight Time",
"Asia/Calcutta"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+05:30) Chennai, Kolkata, Mumbai, New
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* Delhi */
{
"Iran Standard Time", "Iran Daylight Time",
"Asia/Tehran"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+03:30) Tehran */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Jerusalem Standard Time", "Jerusalem Daylight Time",
"Asia/Jerusalem"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+02:00) Jerusalem */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Jordan Standard Time", "Jordan Daylight Time",
"Asia/Amman"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+02:00) Amman */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Kamchatka Standard Time", "Kamchatka Daylight Time",
"Asia/Kamchatka"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+12:00) Petropavlovsk-Kamchatsky - Old */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Korea Standard Time", "Korea Daylight Time",
"Asia/Seoul"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+09:00) Seoul */
{
"Libya Standard Time", "Libya Daylight Time",
"Africa/Tripoli"
}, /* (UTC+02:00) Tripoli */
{
"Line Islands Standard Time", "Line Islands Daylight Time",
"Pacific/Kiritimati"
}, /* (UTC+14:00) Kiritimati Island */
{
"Lord Howe Standard Time", "Lord Howe Daylight Time",
"Australia/Lord_Howe"
}, /* (UTC+10:30) Lord Howe Island */
{
"Magadan Standard Time", "Magadan Daylight Time",
"Asia/Magadan"
}, /* (UTC+10:00) Magadan */
{
"Marquesas Standard Time", "Marquesas Daylight Time",
"Pacific/Marquesas"
}, /* (UTC-09:30) Marquesas Islands */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Mauritius Standard Time", "Mauritius Daylight Time",
"Indian/Mauritius"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+04:00) Port Louis */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Mexico Standard Time", "Mexico Daylight Time",
"America/Mexico_City"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-06:00) Guadalajara, Mexico City,
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* Monterrey */
{
"Mexico Standard Time 2", "Mexico Daylight Time 2",
"America/Chihuahua"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-07:00) Chihuahua, La Paz, Mazatlan */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Mid-Atlantic Standard Time", "Mid-Atlantic Daylight Time",
"Atlantic/South_Georgia"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-02:00) Mid-Atlantic - Old */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Middle East Standard Time", "Middle East Daylight Time",
"Asia/Beirut"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+02:00) Beirut */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Montevideo Standard Time", "Montevideo Daylight Time",
"America/Montevideo"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-03:00) Montevideo */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Morocco Standard Time", "Morocco Daylight Time",
"Africa/Casablanca"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC) Casablanca */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Mountain Standard Time", "Mountain Daylight Time",
"US/Mountain"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-07:00) Mountain Time (US & Canada) */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Mountain Standard Time (Mexico)", "Mountain Daylight Time (Mexico)",
"America/Chihuahua"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-07:00) Chihuahua, La Paz, Mazatlan */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Myanmar Standard Time", "Myanmar Daylight Time",
"Asia/Rangoon"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+06:30) Yangon (Rangoon) */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"N. Central Asia Standard Time", "N. Central Asia Daylight Time",
"Asia/Novosibirsk"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+06:00) Novosibirsk (RTZ 5) */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Namibia Standard Time", "Namibia Daylight Time",
"Africa/Windhoek"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+01:00) Windhoek */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Nepal Standard Time", "Nepal Daylight Time",
"Asia/Katmandu"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+05:45) Kathmandu */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"New Zealand Standard Time", "New Zealand Daylight Time",
"Pacific/Auckland"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+12:00) Auckland, Wellington */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Newfoundland Standard Time", "Newfoundland Daylight Time",
"Canada/Newfoundland"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-03:30) Newfoundland */
{
"Norfolk Standard Time", "Norfolk Daylight Time",
"Pacific/Norfolk"
}, /* (UTC+11:00) Norfolk Island */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"North Asia East Standard Time", "North Asia East Daylight Time",
"Asia/Irkutsk"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+08:00) Irkutsk, Ulaan Bataar */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"North Asia Standard Time", "North Asia Daylight Time",
"Asia/Krasnoyarsk"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+07:00) Krasnoyarsk */
{
"North Korea Standard Time", "North Korea Daylight Time",
"Asia/Pyongyang"
}, /* (UTC+08:30) Pyongyang */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Pacific SA Standard Time", "Pacific SA Daylight Time",
"America/Santiago"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-03:00) Santiago */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Pacific Standard Time", "Pacific Daylight Time",
"US/Pacific"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-08:00) Pacific Time (US & Canada) */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Pacific Standard Time (Mexico)", "Pacific Daylight Time (Mexico)",
"America/Tijuana"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-08:00) Baja California */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Pakistan Standard Time", "Pakistan Daylight Time",
"Asia/Karachi"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+05:00) Islamabad, Karachi */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Paraguay Standard Time", "Paraguay Daylight Time",
"America/Asuncion"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-04:00) Asuncion */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Romance Standard Time", "Romance Daylight Time",
"Europe/Brussels"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+01:00) Brussels, Copenhagen, Madrid,
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* Paris */
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
{
"Russia TZ 1 Standard Time", "Russia TZ 1 Daylight Time",
"Europe/Kaliningrad"
}, /* (UTC+02:00) Kaliningrad (RTZ 1) */
{
"Russia TZ 2 Standard Time", "Russia TZ 2 Daylight Time",
"Europe/Moscow"
}, /* (UTC+03:00) Moscow, St. Petersburg,
* Volgograd (RTZ 2) */
{
"Russia TZ 3 Standard Time", "Russia TZ 3 Daylight Time",
"Europe/Samara"
}, /* (UTC+04:00) Izhevsk, Samara (RTZ 3) */
{
"Russia TZ 4 Standard Time", "Russia TZ 4 Daylight Time",
"Asia/Yekaterinburg"
}, /* (UTC+05:00) Ekaterinburg (RTZ 4) */
{
"Russia TZ 5 Standard Time", "Russia TZ 5 Daylight Time",
"Asia/Novosibirsk"
}, /* (UTC+06:00) Novosibirsk (RTZ 5) */
{
"Russia TZ 6 Standard Time", "Russia TZ 6 Daylight Time",
"Asia/Krasnoyarsk"
}, /* (UTC+07:00) Krasnoyarsk (RTZ 6) */
{
"Russia TZ 7 Standard Time", "Russia TZ 7 Daylight Time",
"Asia/Irkutsk"
}, /* (UTC+08:00) Irkutsk (RTZ 7) */
{
"Russia TZ 8 Standard Time", "Russia TZ 8 Daylight Time",
"Asia/Yakutsk"
}, /* (UTC+09:00) Yakutsk (RTZ 8) */
{
"Russia TZ 9 Standard Time", "Russia TZ 9 Daylight Time",
"Asia/Vladivostok"
Post-PG 10 beta1 pgindent run perltidy run not included.
2017-05-17 22:31:56 +02:00
}, /* (UTC+10:00) Vladivostok, Magadan (RTZ 9) */
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
{
"Russia TZ 10 Standard Time", "Russia TZ 10 Daylight Time",
"Asia/Magadan"
}, /* (UTC+11:00) Chokurdakh (RTZ 10) */
{
"Russia TZ 11 Standard Time", "Russia TZ 11 Daylight Time",
"Asia/Anadyr"
Post-PG 10 beta1 pgindent run perltidy run not included.
2017-05-17 22:31:56 +02:00
}, /* (UTC+12:00) Anadyr,
* Petropavlovsk-Kamchatsky (RTZ 11) */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Russian Standard Time", "Russian Daylight Time",
"Europe/Moscow"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+03:00) Moscow, St. Petersburg,
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* Volgograd */
{
"SA Eastern Standard Time", "SA Eastern Daylight Time",
"America/Buenos_Aires"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-03:00) Cayenne, Fortaleza */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"SA Pacific Standard Time", "SA Pacific Daylight Time",
"America/Bogota"
Post-PG 10 beta1 pgindent run perltidy run not included.
2017-05-17 22:31:56 +02:00
}, /* (UTC-05:00) Bogota, Lima, Quito, Rio Branco */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"SA Western Standard Time", "SA Western Daylight Time",
"America/Caracas"
Post-PG 10 beta1 pgindent run perltidy run not included.
2017-05-17 22:31:56 +02:00
}, /* (UTC-04:00) Georgetown, La Paz, Manaus, San
* Juan */
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
{
"Saint Pierre Standard Time", "Saint Pierre Daylight Time",
"America/Miquelon"
}, /* (UTC-03:00) Saint Pierre and Miquelon */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Samoa Standard Time", "Samoa Daylight Time",
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
"Pacific/Samoa"
}, /* (UTC+13:00) Samoa */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"SE Asia Standard Time", "SE Asia Daylight Time",
"Asia/Bangkok"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+07:00) Bangkok, Hanoi, Jakarta */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Malay Peninsula Standard Time", "Malay Peninsula Daylight Time",
"Asia/Kuala_Lumpur"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+08:00) Kuala Lumpur, Singapore */
{
"Sakhalin Standard Time", "Sakhalin Daylight Time",
"Asia/Sakhalin"
}, /* (UTC+11:00) Sakhalin */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"South Africa Standard Time", "South Africa Daylight Time",
"Africa/Harare"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+02:00) Harare, Pretoria */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Sri Lanka Standard Time", "Sri Lanka Daylight Time",
"Asia/Colombo"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+05:30) Sri Jayawardenepura */
{
"Syria Standard Time", "Syria Daylight Time",
"Asia/Damascus"
}, /* (UTC+02:00) Damascus */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Taipei Standard Time", "Taipei Daylight Time",
"Asia/Taipei"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+08:00) Taipei */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Tasmania Standard Time", "Tasmania Daylight Time",
"Australia/Hobart"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+10:00) Hobart */
{
"Tocantins Standard Time", "Tocantins Daylight Time",
"America/Araguaina"
}, /* (UTC-03:00) Araguaina */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Tokyo Standard Time", "Tokyo Daylight Time",
"Asia/Tokyo"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+09:00) Osaka, Sapporo, Tokyo */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Tonga Standard Time", "Tonga Daylight Time",
"Pacific/Tongatapu"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+13:00) Nuku'alofa */
{
"Tomsk Standard Time", "Tomsk Daylight Time",
"Asia/Tomsk"
}, /* (UTC+07:00) Tomsk */
{
"Transbaikal Standard Time", "Transbaikal Daylight Time",
"Asia/Chita"
}, /* (UTC+09:00) Chita */
{
"Turkey Standard Time", "Turkey Daylight Time",
"Europe/Istanbul"
}, /* (UTC+02:00) Istanbul */
{
"Turks and Caicos Standard Time", "Turks and Caicos Daylight Time",
"America/Grand_Turk"
}, /* (UTC-04:00) Turks and Caicos */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Ulaanbaatar Standard Time", "Ulaanbaatar Daylight Time",
"Asia/Ulaanbaatar",
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+08:00) Ulaanbaatar */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"US Eastern Standard Time", "US Eastern Daylight Time",
"US/Eastern"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-05:00) Indiana (East) */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"US Mountain Standard Time", "US Mountain Daylight Time",
"US/Arizona"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-07:00) Arizona */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Coordinated Universal Time", "Coordinated Universal Time",
"UTC"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC) Coordinated Universal Time */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"UTC+12", "UTC+12",
"Etc/GMT+12"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+12:00) Coordinated Universal Time+12 */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"UTC-02", "UTC-02",
"Etc/GMT-02"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-02:00) Coordinated Universal Time-02 */
{
"UTC-08", "UTC-08",
"Etc/GMT-08"
}, /* (UTC-08:00) Coordinated Universal Time-08 */
{
"UTC-09", "UTC-09",
"Etc/GMT-09"
}, /* (UTC-09:00) Coordinated Universal Time-09 */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"UTC-11", "UTC-11",
"Etc/GMT-11"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-11:00) Coordinated Universal Time-11 */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Venezuela Standard Time", "Venezuela Daylight Time",
"America/Caracas",
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC-04:30) Caracas */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Vladivostok Standard Time", "Vladivostok Daylight Time",
"Asia/Vladivostok"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+10:00) Vladivostok (RTZ 9) */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"W. Australia Standard Time", "W. Australia Daylight Time",
"Australia/Perth"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+08:00) Perth */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
#ifdef NOT_USED
/* Could not find a match for this one (just a guess). Excluded for now. */
{
"W. Central Africa Standard Time", "W. Central Africa Daylight Time",
"WAT"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+01:00) West Central Africa */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
#endif
{
"W. Europe Standard Time", "W. Europe Daylight Time",
"CET"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+01:00) Amsterdam, Berlin, Bern, Rome,
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
* Stockholm, Vienna */
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
{
"W. Mongolia Standard Time", "W. Mongolia Daylight Time",
"Asia/Hovd"
}, /* (UTC+07:00) Hovd */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"West Asia Standard Time", "West Asia Daylight Time",
"Asia/Karachi"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+05:00) Ashgabat, Tashkent */
{
"West Bank Gaza Standard Time", "West Bank Gaza Daylight Time",
"Asia/Gaza"
}, /* (UTC+02:00) Gaza, Hebron */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"West Pacific Standard Time", "West Pacific Daylight Time",
"Pacific/Guam"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+10:00) Guam, Port Moresby */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
"Yakutsk Standard Time", "Yakutsk Daylight Time",
"Asia/Yakutsk"
Update Windows timezone mapping from Windows 7 and 10 This adds a couple of new timezones that are present in the newer versions of Windows. It also updates comments to reference UTC rather than GMT, as this change has been made in Windows. Michael Paquier
2016-08-18 12:32:42 +02:00
}, /* (UTC+09:00) Yakutsk */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
{
NULL, NULL, NULL
}
};
static const char *
identify_system_timezone(void)
{
int i;
char tzname[128];
char localtzname[256];
time_t t = time(NULL);
struct tm *tm = localtime(&t);
HKEY rootKey;
int idx;
if (!tm)
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "could not identify system time zone: localtime() failed\n");
#endif
return NULL; /* go to GMT */
}
memset(tzname, 0, sizeof(tzname));
strftime(tzname, sizeof(tzname) - 1, "%Z", tm);
for (i = 0; win32_tzmap[i].stdname != NULL; i++)
{
if (strcmp(tzname, win32_tzmap[i].stdname) == 0 ||
strcmp(tzname, win32_tzmap[i].dstname) == 0)
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "TZ \"%s\" matches system time zone \"%s\"\n",
win32_tzmap[i].pgtzname, tzname);
#endif
return win32_tzmap[i].pgtzname;
}
}
/*
* Localized Windows versions return localized names for the timezone.
* Scan the registry to find the English name, and then try matching
* against our table again.
*/
memset(localtzname, 0, sizeof(localtzname));
if (RegOpenKeyEx(HKEY_LOCAL_MACHINE,
Phase 3 of pgindent updates. Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
"SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Time Zones",
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
0,
KEY_READ,
&rootKey) != ERROR_SUCCESS)
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "could not open registry key to identify system time zone: error code %lu\n",
GetLastError());
#endif
return NULL; /* go to GMT */
}
for (idx = 0;; idx++)
{
char keyname[256];
char zonename[256];
DWORD namesize;
FILETIME lastwrite;
HKEY key;
LONG r;
memset(keyname, 0, sizeof(keyname));
namesize = sizeof(keyname);
if ((r = RegEnumKeyEx(rootKey,
idx,
keyname,
&namesize,
NULL,
NULL,
NULL,
&lastwrite)) != ERROR_SUCCESS)
{
if (r == ERROR_NO_MORE_ITEMS)
break;
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "could not enumerate registry subkeys to identify system time zone: %d\n",
(int) r);
#endif
break;
}
if ((r = RegOpenKeyEx(rootKey, keyname, 0, KEY_READ, &key)) != ERROR_SUCCESS)
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "could not open registry subkey to identify system time zone: %d\n",
(int) r);
#endif
break;
}
memset(zonename, 0, sizeof(zonename));
namesize = sizeof(zonename);
if ((r = RegQueryValueEx(key, "Std", NULL, NULL, (unsigned char *) zonename, &namesize)) != ERROR_SUCCESS)
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "could not query value for key \"std\" to identify system time zone \"%s\": %d\n",
keyname, (int) r);
#endif
RegCloseKey(key);
continue; /* Proceed to look at the next timezone */
}
if (strcmp(tzname, zonename) == 0)
{
/* Matched zone */
strcpy(localtzname, keyname);
RegCloseKey(key);
break;
}
memset(zonename, 0, sizeof(zonename));
namesize = sizeof(zonename);
if ((r = RegQueryValueEx(key, "Dlt", NULL, NULL, (unsigned char *) zonename, &namesize)) != ERROR_SUCCESS)
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "could not query value for key \"dlt\" to identify system time zone \"%s\": %d\n",
keyname, (int) r);
#endif
RegCloseKey(key);
continue; /* Proceed to look at the next timezone */
}
if (strcmp(tzname, zonename) == 0)
{
/* Matched DST zone */
strcpy(localtzname, keyname);
RegCloseKey(key);
break;
}
RegCloseKey(key);
}
RegCloseKey(rootKey);
if (localtzname[0])
{
/* Found a localized name, so scan for that one too */
for (i = 0; win32_tzmap[i].stdname != NULL; i++)
{
if (strcmp(localtzname, win32_tzmap[i].stdname) == 0 ||
strcmp(localtzname, win32_tzmap[i].dstname) == 0)
{
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "TZ \"%s\" matches localized system time zone \"%s\" (\"%s\")\n",
win32_tzmap[i].pgtzname, tzname, localtzname);
#endif
return win32_tzmap[i].pgtzname;
}
}
}
#ifdef DEBUG_IDENTIFY_TIMEZONE
fprintf(stderr, "could not find a match for system time zone \"%s\"\n",
tzname);
#endif
return NULL; /* go to GMT */
}
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* WIN32 */
Simplify handling of the timezone GUC by making initdb choose the default. We were doing some amazingly complicated things in order to avoid running the very expensive identify_system_timezone() procedure during GUC initialization. But there is an obvious fix for that, which is to do it once during initdb and have initdb install the system-specific default into postgresql.conf, as it already does for most other GUC variables that need system-environment-dependent defaults. This means that the timezone (and log_timezone) settings no longer have any magic behavior in the server. Per discussion.
2011-09-09 23:59:11 +02:00
/*
* Return true if the given zone name is valid and is an "acceptable" zone.
*/
static bool
validate_zone(const char *tzname)
{
pg_tz *tz;
if (!tzname || !tzname[0])
return false;
tz = pg_load_tz(tzname);
if (!tz)
return false;
if (!pg_tz_acceptable(tz))
return false;
return true;
}
/*
* Identify a suitable default timezone setting based on the environment.
*
* The installation share_path must be passed in, as that is the default
* location for the timezone database directory.
*
* We first look to the TZ environment variable. If not found or not
* recognized by our own code, we see if we can identify the timezone
* from the behavior of the system timezone library. When all else fails,
* return NULL, indicating that we should default to GMT.
*/
const char *
select_default_timezone(const char *share_path)
{
const char *tzname;
/* Initialize timezone directory path, if needed */
#ifndef SYSTEMTZDIR
snprintf(tzdirpath, sizeof(tzdirpath), "%s/timezone", share_path);
#endif
/* Check TZ environment variable */
tzname = getenv("TZ");
if (validate_zone(tzname))
return tzname;
/* Nope, so try to identify the system timezone */
tzname = identify_system_timezone();
if (validate_zone(tzname))
return tzname;
return NULL;
}