time.Parse currently rejects numeric timezones names with UTC offsets
bigger than +12, but this is incorrect: there's a +13 timezone and a
+14 timezone:

  $ zdump Pacific/Kiritimati
  Pacific/Kiritimati  Mon Jun 25 02:15:03 2018 +14

For convenience, this cl changes the ranges of accepted offsets from
-14..+12 to -23..+23 (zero still excluded), i.e. every possible offset
that makes sense. We don't validate three-letter abbreviations for the
timezones names, so there's no need to be too strict on numeric names.

This change also fixes a bug in the parseTimeZone, that is currently
unconditionally returning true (i.e. valid timezone), without checking
the value returned by parseSignedOffset.

This fixes 5 of 17 time.Parse() failures listed in Issue #26032.

Updates #26032

Change-Id: I2f08ca9aa41ea4c6149ed35ed2dd8f23eeb42bff
Reviewed-on: https://go-review.googlesource.com/120558
Reviewed-by: Rob Pike <r@golang.org>

A timezone with a zero offset from UTC and without a three-letter
abbreviation will have a numeric name in timestamps: "+00".

There are currently two of them:

  $ zdump Atlantic/Azores America/Scoresbysund
  Atlantic/Azores       Wed Aug 22 09:01:05 2018 +00
  America/Scoresbysund  Wed Aug 22 09:01:05 2018 +00

These two timestamp are rejected by Parse, since it doesn't allow for
zero offsets:

  parsing time "Wed Aug 22 09:01:05 2018 +00": extra text: +00

This change modifies Parse to accept a +00 offset in numeric timezone
names.

As side effect of this change, Parse also now accepts "GMT+00". It was
explicitely disallowed (with a unit test ensuring it got rejected),
but the restriction seems incorrect.

DATE(1), for example, allows it:

  $ date --debug --date="2009-01-02 03:04:05 GMT+00"

  date: parsed date part: (Y-M-D) 2009-01-02
  date: parsed time part: 03:04:05
  date: parsed zone part: UTC+00
  date: input timezone: parsed date/time string (+00)
  date: using specified time as starting value: '03:04:05'
  date: starting date/time: '(Y-M-D) 2009-01-02 03:04:05 TZ=+00'
  date: '(Y-M-D) 2009-01-02 03:04:05 TZ=+00' = 1230865445 epoch-seconds
  date: timezone: system default
  date: final: 1230865445.000000000 (epoch-seconds)
  date: final: (Y-M-D) 2009-01-02 03:04:05 (UTC)
  date: final: (Y-M-D) 2009-01-02 04:04:05 (UTC+01)
  Fri  2 Jan 04:04:05 CET 2009

This fixes 2 of 17 time.Parse() failures listed in Issue #26032.

Updates #26032

Change-Id: I01cd067044371322b7bb1dae452fb3c758ed3cc2
Reviewed-on: https://go-review.googlesource.com/130696
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

With this CL Parse accepts all of `timedatectl list-timezones | xargs zdump`

Fixes golang#26032

With this CL Parse accepts all of `timedatectl list-timezones | xargs zdump`

Fixes golang#26032

With this CL Parse accepts all of `timedatectl list-timezones | xargs zdump`

Fixes golang#26032