database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list

Browse Source 
provided by Andrew.
This commit is contained in:
Bruce Momjian
2009-06-11 14:49:15 +00:00
parent 4e86efb4e5
commit d747140279
654 changed files with 11900 additions and 11387 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
src/timezone/pgtz.c
View File

@ -6,7 +6,7 @@
* Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/timezone/pgtz.c,v 1.62 2009/01/01 17:24:04 momjian Exp $
* $PostgreSQL: pgsql/src/timezone/pgtz.c,v 1.63 2009/06/11 14:49:15 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -387,15 +387,15 @@ identify_system_timezone(void)
* 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 allows us to recognize zones that have some
* commonality with the zic database, without insisting on exact match.
* (Note: we probe Thursdays, not Sundays, to avoid triggering
* DST-transition bugs in localtime itself.)
* 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
* allows us to recognize zones that have some commonality with the zic
* 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);
@ -404,6 +404,7 @@ identify_system_timezone(void)
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
@ -731,7 +732,7 @@ static const struct
"Central Standard Time (Mexico)", "Central Daylight Time (Mexico)",
"America/Mexico_City"
}, /* (GMT-06:00) Guadalajara, Mexico City,
Monterrey - New */
* Monterrey - New */
{
"China Standard Time", "China Daylight Time",
"Asia/Hong_Kong"
@ -852,8 +853,8 @@ static const struct
{
"Mountain Standard Time (Mexico)", "Mountain Daylight Time (Mexico)",
"America/Chihuahua"
}, /* (GMT-07:00) Chihuahua, La Paz,
Mazatlan - New */
}, /* (GMT-07:00) Chihuahua, La Paz, Mazatlan -
* New */
{
"Myanmar Standard Time", "Myanmar Daylight Time",
"Asia/Rangoon"
@ -974,7 +975,7 @@ static const struct
"Australia/Perth"
}, /* (GMT+08:00) Perth */
/* {"W. Central Africa Standard Time", "W. Central Africa Daylight Time",
* * * * * * * ""}, Could not find a match for this one. Excluded for now. *//* (
* * * * * * * * ""}, Could not find a match for this one. Excluded for now. *//* (
* G MT+01:00) West Central Africa */
{
"W. Europe Standard Time", "W. Europe Daylight Time",
@ -1492,7 +1493,7 @@ pg_tzenumerate_next(pg_tzenum *dir)
* Load this timezone using tzload() not pg_tzset(), so we don't fill
* the cache
*/
if (tzload(fullname + dir->baselen, dir->tz.TZname, &dir->tz.state,
if (tzload(fullname + dir->baselen, dir->tz.TZname, &dir->tz.state,
TRUE) != 0)
{
/* Zone could not be loaded, ignore it */