Re: [BUGS] BUG #2977: dow doesn't conform to ISO-8601 - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: [BUGS] BUG #2977: dow doesn't conform to ISO-8601
Date
Msg-id 200702191744.l1JHiSw15345@momjian.us
Whole thread Raw
In response to Re: [BUGS] BUG #2977: dow doesn't conform to ISO-8601  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [BUGS] BUG #2977: dow doesn't conform to ISO-8601
List pgsql-patches
Updated version applied.  I reduced the numering changes for the macros.

There was also documentation text for "dow" and a few others that said
"(for <type>timestamp</type> values only)", but in fact the field worked
for "timestamptz" and "date" too, so I removed the mentions.  If people
get confused, I will come up with new wording, like "doesn't work for
interval or time", which I think is pretty obvious.  I remember people
got confused in the past about this, so maybe we still need something.

---------------------------------------------------------------------------

Bruce Momjian wrote:
>
> I have implemented 'isodow' with the attached patch.
>
> ---------------------------------------------------------------------------
>
> Peter Eisentraut wrote:
> > Am Mittwoch, 7. Februar 2007 11:24 schrieb Adriaan van Os:
> > > Section 9.9.1 of the Postgres docs
> > > <http://www.postgresql.org/docs/8.2/interactive/functions-datetime.html>
> > > mentions that the "week" subfield of the date_part function conforms to the
> > > ISO-8601 standard.
> >
> > I see no such claim there.
> >
> > > You can not, in the same function, ignore ISO-8601 for one subfield and
> > > follow it in another.
> >
> > I think we have pretty well shown that we can.
> >
> > > Besides, if in the same week Sunday comes before Monday, how can the result
> > > of the "week" and "dow" fields conform to each other ?
> >
> > They don't.
> >
> > > If "dow" can not be changed for reasons of backward compatibility, I
> > > suggest a new subfield "dayofweek" that does conform to the standard.
> >
> > That might be reasonable. (Or maybe "isodow".)
> >
> > --
> > Peter Eisentraut
> > http://developer.postgresql.org/~petere/
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
>
> --
>   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. +


>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
  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: doc/src/sgml/func.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/func.sgml,v
retrieving revision 1.361
diff -c -c -r1.361 func.sgml
*** doc/src/sgml/func.sgml    16 Feb 2007 07:46:54 -0000    1.361
--- doc/src/sgml/func.sgml    19 Feb 2007 17:38:23 -0000
***************
*** 5732,5739 ****
        <term><literal>dow</literal></term>
        <listitem>
         <para>
!         The day of the week (0 - 6; Sunday is 0) (for
!         <type>timestamp</type> values only)
         </para>

  <screen>
--- 5732,5739 ----
        <term><literal>dow</literal></term>
        <listitem>
         <para>
!         The day of the week as Sunday(<literal>0</>) to
!         Saturday(<literal>6</>)
         </para>

  <screen>
***************
*** 5741,5747 ****
  <lineannotation>Result: </lineannotation><computeroutput>5</computeroutput>
  </screen>
         <para>
!         Note that <function>extract</function>'s day of the week numbering is
          different from that of the <function>to_char</function> function.
         </para>

--- 5741,5747 ----
  <lineannotation>Result: </lineannotation><computeroutput>5</computeroutput>
  </screen>
         <para>
!         Note that <function>extract</function>'s day of the week numbering is
          different from that of the <function>to_char</function> function.
         </para>

***************
*** 5752,5758 ****
        <term><literal>doy</literal></term>
        <listitem>
         <para>
!         The day of the year (1 - 365/366) (for <type>timestamp</type> values only)
         </para>

  <screen>
--- 5752,5758 ----
        <term><literal>doy</literal></term>
        <listitem>
         <para>
!         The day of the year (1 - 365/366)
         </para>

  <screen>
***************
*** 5806,5811 ****
--- 5806,5831 ----
       </varlistentry>

       <varlistentry>
+       <term><literal>isodow</literal></term>
+       <listitem>
+        <para>
+         The day of the week as Monday(<literal>1</>) to
+         Sunday(<literal>7</>)
+        </para>
+
+ <screen>
+ SELECT EXTRACT(ISODOW FROM TIMESTAMP '2001-02-18 20:38:40');
+ <lineannotation>Result: </lineannotation><computeroutput>7</computeroutput>
+ </screen>
+        <para>
+         This is identical to <literal>dow</> except for Sunday.  This
+         matches the <acronym>ISO</> 8601 day of the week numbering.
+        </para>
+
+       </listitem>
+      </varlistentry>
+
+      <varlistentry>
        <term><literal>isoyear</literal></term>
        <listitem>
         <para>
***************
*** 5923,5930 ****
        <term><literal>quarter</literal></term>
        <listitem>
         <para>
!         The quarter of the year (1 - 4) that the day is in (for
!         <type>timestamp</type> values only)
         </para>

  <screen>
--- 5943,5949 ----
        <term><literal>quarter</literal></term>
        <listitem>
         <para>
!         The quarter of the year (1 - 4) that the day is in
         </para>

  <screen>
***************
*** 5989,5995 ****
          (<acronym>ISO</acronym> 8601), the first week of a year
          contains January 4 of that year.  (The <acronym>ISO</acronym>-8601
          week starts on Monday.)  In other words, the first Thursday of
!         a year is in week 1 of that year. (for <type>timestamp</type> values only)
         </para>
         <para>
          Because of this, it is possible for early January dates to be part of the
--- 6008,6014 ----
          (<acronym>ISO</acronym> 8601), the first week of a year
          contains January 4 of that year.  (The <acronym>ISO</acronym>-8601
          week starts on Monday.)  In other words, the first Thursday of
!         a year is in week 1 of that year.
         </para>
         <para>
          Because of this, it is possible for early January dates to be part of the
Index: src/backend/utils/adt/datetime.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/datetime.c,v
retrieving revision 1.176
diff -c -c -r1.176 datetime.c
*** src/backend/utils/adt/datetime.c    16 Feb 2007 03:39:45 -0000    1.176
--- src/backend/utils/adt/datetime.c    19 Feb 2007 17:38:25 -0000
***************
*** 125,130 ****
--- 125,131 ----
      {"h", UNITS, DTK_HOUR},        /* "hour" */
      {LATE, RESERV, DTK_LATE},    /* "infinity" reserved for "late time" */
      {INVALID, RESERV, DTK_INVALID},        /* "invalid" reserved for bad time */
+     {"isodow", RESERV, DTK_ISODOW},        /* ISO day of week, Sunday == 7 */
      {"isoyear", UNITS, DTK_ISOYEAR},    /* year in terms of the ISO week date */
      {"j", UNITS, DTK_JULIAN},
      {"jan", MONTH, 1},
Index: src/backend/utils/adt/timestamp.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v
retrieving revision 1.172
diff -c -c -r1.172 timestamp.c
*** src/backend/utils/adt/timestamp.c    16 Feb 2007 03:39:45 -0000    1.172
--- src/backend/utils/adt/timestamp.c    19 Feb 2007 17:38:26 -0000
***************
*** 4112,4122 ****
--- 4112,4125 ----
                      break;
                  }
              case DTK_DOW:
+             case DTK_ISODOW:
                  if (timestamp2tm(timestamp, NULL, tm, &fsec, NULL, NULL) != 0)
                      ereport(ERROR,
                              (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
                               errmsg("timestamp out of range")));
                  result = j2day(date2j(tm->tm_year, tm->tm_mon, tm->tm_mday));
+                 if (val == DTK_ISODOW && result == 0)
+                     result = 7;
                  break;

              case DTK_DOY:
***************
*** 4322,4332 ****
--- 4325,4338 ----
                  break;

              case DTK_DOW:
+             case DTK_ISODOW:
                  if (timestamp2tm(timestamp, &tz, tm, &fsec, &tzn, NULL) != 0)
                      ereport(ERROR,
                              (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
                               errmsg("timestamp out of range")));
                  result = j2day(date2j(tm->tm_year, tm->tm_mon, tm->tm_mday));
+                 if (val == DTK_ISODOW && result == 0)
+                     result = 7;
                  break;

              case DTK_DOY:
Index: src/include/utils/datetime.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/utils/datetime.h,v
retrieving revision 1.64
diff -c -c -r1.64 datetime.h
*** src/include/utils/datetime.h    16 Feb 2007 03:39:45 -0000    1.64
--- src/include/utils/datetime.h    19 Feb 2007 17:38:27 -0000
***************
*** 166,171 ****
--- 166,172 ----
  #define DTK_TZ_HOUR        34
  #define DTK_TZ_MINUTE    35
  #define DTK_ISOYEAR        36
+ #define DTK_ISODOW        37


  /*
Index: src/interfaces/ecpg/pgtypeslib/dt.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/dt.h,v
retrieving revision 1.35
diff -c -c -r1.35 dt.h
*** src/interfaces/ecpg/pgtypeslib/dt.h    16 Feb 2007 03:39:45 -0000    1.35
--- src/interfaces/ecpg/pgtypeslib/dt.h    19 Feb 2007 17:38:27 -0000
***************
*** 158,163 ****
--- 158,164 ----
  #define DTK_TZ_HOUR        34
  #define DTK_TZ_MINUTE    35
  #define DTK_ISOYEAR        36
+ #define DTK_ISODOW        37


  /*
Index: src/interfaces/ecpg/pgtypeslib/dt_common.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/dt_common.c,v
retrieving revision 1.36
diff -c -c -r1.36 dt_common.c
*** src/interfaces/ecpg/pgtypeslib/dt_common.c    26 Sep 2006 07:56:56 -0000    1.36
--- src/interfaces/ecpg/pgtypeslib/dt_common.c    19 Feb 2007 17:38:28 -0000
***************
*** 214,219 ****
--- 214,220 ----
      {"irkst", DTZ, POS(36)},    /* Irkutsk Summer Time */
      {"irkt", TZ, POS(32)},        /* Irkutsk Time */
      {"irt", TZ, POS(14)},        /* Iran Time */
+     {"isodow", RESERV, DTK_ISODOW},    /* ISO day of week, Sunday == 7 */
  #if 0
      isst
  #endif

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: WIP patch - INSERT-able log statements
Next
From: Heikki Linnakangas
Date:
Subject: Re: Recalculating OldestXmin in a long-running vacuum