*
*
* IDENTIFICATION
- * $Header: /cvsroot/pgsql/src/backend/utils/adt/date.c,v 1.75 2003/01/09 01:06:57 tgl Exp $
+ * $Header: /cvsroot/pgsql/src/backend/utils/adt/date.c,v 1.76 2003/01/22 20:44:20 tgl Exp $
*
*-------------------------------------------------------------------------
*/
/*
* 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,
+ * values. On most platforms, rint() will implement round-to-nearest-even,
* but the integer code always rounds up (away from zero). Is it
* worth trying to be consistent?
*/
*
*
* IDENTIFICATION
- * $Header: /cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v 1.76 2003/01/09 01:06:57 tgl Exp $
+ * $Header: /cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v 1.77 2003/01/22 20:44:20 tgl Exp $
*
*-------------------------------------------------------------------------
*/
/*
* 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,
+ * values. On most platforms, rint() will implement round-to-nearest-even,
* but the integer code always rounds up (away from zero). Is it
* worth trying to be consistent?
*/
/*
* 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,
+ * values. On most platforms, rint() will implement round-to-nearest-even,
* but the integer code always rounds up (away from zero). Is it
* worth trying to be consistent?
*/