Tom Lane wrote:
> "Brendan Jurd" <direvus@gmail.com> writes:
> > However, in from_char(), the reverse is not true. Looking at the code
> > snippet above, the digit is scanned straight into tmfc->d unaltered
> > (this value is later copied directly to tm->tm_wday circa line 3394).
> > Unless I'm missing something, when converting to text, 'D' yields 1-7,
> > but when converting back from text, 'D' expects 0-6.
>
> Although this does look like a bug, I'm not sure it matters, because
> AFAICS there is no code path that will look at the value of tm_wday
> while constructing a timestamp value from a struct tm. I'm inclined
> not to risk messing with it just before RC1 unless a visible fault
> can be demonstrated.
Fixed in 8.3, patch attached.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/utils/adt/formatting.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/formatting.c,v
retrieving revision 1.123
diff -c -c -r1.123 formatting.c
*** src/backend/utils/adt/formatting.c 13 Feb 2007 02:00:55 -0000 1.123
--- src/backend/utils/adt/formatting.c 14 Feb 2007 05:07:34 -0000
***************
*** 2484,2489 ****
--- 2484,2490 ----
else
{
sscanf(inout, "%1d", &tmfc->d);
+ tmfc->d--;
return strspace_len(inout) + 1 + SKIP_THth(suf);
}
break;
