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>
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>
CL 78735 description:
time: add space padding layout strings(using underscore) for not only day but others
As mentioned in #22802, only day component of layout string has space
padding(represented by one underscore before its placeholder). This
commit expands the rule for month, hour, minute and second.
Updates #22802 (maybe fixes it)
Revert this CL because it breaks currently working formats that happen
to use underscores.
Fixes#23259
Change-Id: I64acaaca9b5b74785ee0f0be7910574e87daa649
Reviewed-on: https://go-review.googlesource.com/85998
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
As mentioned in #22802, only day component of layout string has space
padding(represented by one underscore before its placeholder). This
commit expands the rule for month, hour, minute and second.
Updates #22802 (maybe fixes it)
Change-Id: I886998380489862ab9a324a6774f2e4cf7124122
Reviewed-on: https://go-review.googlesource.com/78735
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The existing implementation will panic when month in date string is '---'.
Fixed#21113
Change-Id: I8058ae7a4102e882f8b7e9c65d80936b563265e4
Reviewed-on: https://go-review.googlesource.com/51010
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When generating a random int8, uint8, int16, uint16, int32, uint32,
quick.Value chooses among all possible values.
But when generating a random int64 or uint64, it only chooses
values in the range [-2⁶², 2⁶²) (even for uint64).
It should, like for all the other integers, use the full range.
If it had, this would have caught #19807 earlier.
Instead it let us discover the presence of #19809.
While we are here, also make the default source of
randomness not completely deterministic.
Fixes#19808.
Change-Id: I070f852531c92b3670bd76523326c9132bfc9416
Reviewed-on: https://go-review.googlesource.com/39152
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The tzdata 2017a update (2017-02-28) changed the abbreviation of the
Asia/Baghdad time zone (used in TestParseInLocation) from 'AST' to the
numeric '+03'.
Update the test so that it skips the checks if we're using a recent
tzdata release.
Fixes#19457
Change-Id: I45d705a5520743a611bdd194dc8f8d618679980c
Reviewed-on: https://go-review.googlesource.com/37964
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Day 0 is as invalid as day 32.
Fixes#17874
Change-Id: I52109d12bafd6d957d00c44d540cb88389fff0a7
Reviewed-on: https://go-review.googlesource.com/33429
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The optional fractional seconds overrides any range error
from the second parsing. Instead don't look for optional fractional
seconds if a range error has occured.
Change-Id: I27e0a2432740f6753668bd8833e48b9495bc4036
Reviewed-on: https://go-review.googlesource.com/27590
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Go 1.5 and earlier said "day out of range".
As part of working on this code it morphed into "day of month out of range".
To avoid churn in the output restore the old text.
This fixes some tests reported privately.
Change-Id: If179676cd49f9a471a9441fec2f5220c85eb0799
Reviewed-on: https://go-review.googlesource.com/18386
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There was back-and-forth on this but it has been decided to fix the original
complaint, which was easy.
Fixes#7268.
Change-Id: I6b607c49ad44579086aba2c4f4c5424b97fbed64
Reviewed-on: https://go-review.googlesource.com/17710
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The existing code has partial support for -07 (just the hours of a time
zone offset). Complete the support, add support for Z07, and add a few
tests.
Fixes#13426.
Change-Id: Ic6377bbf3e65b4bb761b9779f7e80c07ce4f57e8
Reviewed-on: https://go-review.googlesource.com/17260
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Otherwise _2006 is treated as _2 and then an error.
Fixes#11334
Change-Id: I40a385b45e279e9f4538bf419baab72781cdb215
Reviewed-on: https://go-review.googlesource.com/16311
Reviewed-by: Rob Pike <r@golang.org>
In Parse, one can now say Feb 31 or even Feb 99. This is easy
to explain, consistent with time.Date, and even maybe useful.
Fixes#12333.
Fixes#7268. (By disagreeing with it.)
Change-Id: I7b95c842528bed66933681c8b9cc00640fccfcb4
Reviewed-on: https://go-review.googlesource.com/14123
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alberto Donizetti
Michael Kasch
Ian Lance Taylor
Hanjun Kim
Cholerae Hu
Russ Cox
Max Riveiro
Brad Fitzpatrick
Gabriel Russell
Nathan VanBenschoten
Rob Pike
Edward Muller
Marvin Stenger