Message-ID: <1522237846.2820.26.camel@cybertec.at>
Subject: Re: Strange timezone 'math' in 9.6.8
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Ervin Weber <webervin@gmail.com>, pgsql-admin
 <pgsql-admin@postgresql.org>
Date: Wed, 28 Mar 2018 13:50:46 +0200
In-Reply-To: 
 <CAFC4ZFjoVMbFqgj9O0Bz+YSnrfzHrEFWHi-fa1bmWmadfnN6iw@mail.gmail.com>
References: 
	<CAFC4ZFjoVMbFqgj9O0Bz+YSnrfzHrEFWHi-fa1bmWmadfnN6iw@mail.gmail.com>
Organization: Cybertec
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

Ervin Weber wrote:
> Seems that PostgreSQL does do math inside invalid time zone names,
> without reporting any errors to client if time zone name has sign and
> number inside range.
> 
> staging=# show server_version;
>  server_version
> ----------------
>  9.6.8
> (1 row)
> 
> staging=# select now(), now() at time zone 'fubar+167';
>               now              |          timezone
> -------------------------------+----------------------------
>  2018-03-28 09:16:25.897444+00 | 2018-03-21 10:16:25.897444
> (1 row)
> 
> staging=# select now(), now() at time zone 'fubar+168';
> ERROR:  time zone "fubar+168" not recognized

The cause of the error is the following code in src/timezone/localtime.c,
in function "getsecs":

  /*
   * Given a pointer into a time zone string, extract a number of seconds,
   * in hh[:mm[:ss]] form, from the string.
   * If any error occurs, return NULL.
   * Otherwise, return a pointer to the first character not part of the number
   * of seconds.
   */
  static const char *
  getsecs(const char *strp, int32 *secsp)
  {
      int         num;

      /*
       * 'HOURSPERDAY * DAYSPERWEEK - 1' allows quasi-Posix rules like
       * "M10.4.6/26", which does not conform to Posix, but which specifies the
       * equivalent of "02:00 on the first Sunday on or after 23 Oct".
       */
      strp = getnum(strp, &num, 0, HOURSPERDAY * DAYSPERWEEK - 1);
      if (strp == NULL)
          return NULL;

So any time zone offset that is one week or more fails.

The seemingly arbitrary limit is explained by the comment; the code
serves several purposes.

One could argue that time zones offsets beyound 12 or 24 hours should
cause an error, but apart from that the behavior is correct, right?

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com