diff options
| author | Bruce Momjian <bruce@momjian.us> | 2014-05-06 11:26:28 -0400 |
|---|---|---|
| committer | Bruce Momjian <bruce@momjian.us> | 2014-05-06 11:26:28 -0400 |
| commit | 04e15c69d2176849aad40dc8df55761ba0ad0491 (patch) | |
| tree | b35274c9d4f7beaa41f6850977cd41024ce36dfa /src/backend/utils/adt/date.c | |
| parent | 41fdcf71d2b424104e08ce229104b8e8e2840d1b (diff) | |
Remove tabs after spaces in C comments
This was not changed in HEAD, but will be done later as part of a
pgindent run. Future pgindent runs will also do this.
Report by Tom Lane
Backpatch through all supported branches, but not HEAD
Diffstat (limited to 'src/backend/utils/adt/date.c')
| -rw-r--r-- | src/backend/utils/adt/date.c | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/src/backend/utils/adt/date.c b/src/backend/utils/adt/date.c index 8677520cb6f..c92cc8d47fa 100644 --- a/src/backend/utils/adt/date.c +++ b/src/backend/utils/adt/date.c @@ -1290,7 +1290,7 @@ AdjustTimeForTypmod(TimeADT *time, int32 typmod) * Note: this round-to-nearest code is not completely consistent about * rounding values that are exactly halfway between integral values. * On most platforms, rint() will implement round-to-nearest-even, but - * the integer code always rounds up (away from zero). Is it worth + * the integer code always rounds up (away from zero). Is it worth * trying to be consistent? */ #ifdef HAVE_INT64_TIMESTAMP @@ -1638,7 +1638,7 @@ time_interval(PG_FUNCTION_ARGS) * Convert interval to time data type. * * This is defined as producing the fractional-day portion of the interval. - * Therefore, we can just ignore the months field. It is not real clear + * Therefore, we can just ignore the months field. It is not real clear * what to do with negative intervals, but we choose to subtract the floor, * so that, say, '-2 hours' becomes '22:00:00'. */ @@ -2627,7 +2627,7 @@ timetz_zone(PG_FUNCTION_ARGS) pg_tz *tzp; /* - * Look up the requested timezone. First we look in the date token table + * Look up the requested timezone. First we look in the date token table * (to handle cases like "EST"), and if that fails, we look in the * timezone database (to handle cases like "America/New_York"). (This * matches the order in which timestamp input checks the cases; it's |