This gives us better expected information for daylight savings time
transitions in year 2038 and beyond.
Fixes#36654
Change-Id: I5a39aed3c40b184e1d7bb7d6ce3aff5307c4c146
Reviewed-on: https://go-review.googlesource.com/c/go/+/215539
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Quote original values passed as substring of ParseError.Message.
Improves the user experience of ParseDuration by making it
quote its original argument, for example:
_, err := time.ParseDuration("for breakfast")
will now produce an error, which when printed out is:
time: invalid duration "for breakfast"
instead of:
time: invalid duration for breakfast
Adapt test cases for format.Parse and format.ParseDuration.
Fixes#38295
Change-Id: Ife322c8f3c859e1e4e8dd546d4cf0d519b4bfa81
Reviewed-on: https://go-review.googlesource.com/c/go/+/227878
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If we see a racy use of timers, as in concurrent calls to Timer.Reset,
do the operations in an unpredictable order, rather than crashing.
Fixes#37400
Change-Id: Idbac295df2dfd551b6d762909d5040fc532c1b34
Reviewed-on: https://go-review.googlesource.com/c/go/+/221077
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 131196 optimized Time.Sub, but was reverted because
it incorrectly computed the nanoseconds in some edge cases.
This CL adds a test case to enforce the correct behavior
so that a future optimization does not break this again.
Updates #17858
Updates #33677
Change-Id: I596d8302ca6bf721cf7ca11cc6f939639fcbdd43
Reviewed-on: https://go-review.googlesource.com/c/go/+/190524
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reverts commit CL 131196 because there is a bug
in the calculation of nanoseconds.
Fixes#33677
Change-Id: Ic8e94c547ee29b8aeda1b9a5cb9764dbf47b14b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/190497
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
This is primarily achieved by checking for arithmetic overflow
instead of using Add and Equal.
It's a decent performance improvement even though
the function still isn't inlined.
name old time/op new time/op delta
Sub-6 242ns ± 0% 122ns ± 0% -49.59% (p=0.002 n=8+10)
Updates #17858.
Change-Id: I1469b618183c83ea8ea54d5ce277eb15f2ec0f11
Reviewed-on: https://go-review.googlesource.com/c/go/+/131196
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The return values are integers, as opposed to floats, since the fractionals can be derived from multiplying t.Seconds().
Fixes#28564
Change-Id: I3796227e1f64ead39ff0aacfbdce912d952f2994
GitHub-Last-Rev: b843ab740b
GitHub-Pull-Request: golang/go#30819
Reviewed-on: https://go-review.googlesource.com/c/go/+/167387
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Day of year is 002 or __2, in contrast to day-in-month 2 or 02 or _2.
This means there is no way to print a variable-width day-of-year,
but that's probably OK.
Fixes#25689.
Change-Id: I1425d412cb7d2d360e9b3bf74e89566714e2477a
Reviewed-on: https://go-review.googlesource.com/c/go/+/122876
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
If we run into data corruption due to the program accessing timers in
a racy way, do a normal panic rather than a hard crash with "panic
holding locks". The hope is to make the problem less confusing for users.
Fixes#25686
Change-Id: I863417adf21f7f8c088675b67a3acf49a0cdef41
Reviewed-on: https://go-review.googlesource.com/115815
Reviewed-by: Austin Clements <austin@google.com>
The go/printer (and thus gofmt) uses a heuristic to determine
whether to break alignment between elements of an expression
list which is spread across multiple lines. The heuristic only
kicked in if the entry sizes (character length) was above a
certain threshold (20) and the ratio between the previous and
current entry size was above a certain value (4).
This heuristic worked reasonably most of the time, but also
led to unfortunate breaks in many cases where a single entry
was suddenly much smaller (or larger) then the previous one.
The behavior of gofmt was sufficiently mysterious in some of
these situations that many issues were filed against it.
The simplest solution to address this problem is to remove
the heuristic altogether and have a programmer introduce
empty lines to force different alignments if it improves
readability. The problem with that approach is that the
places where it really matters, very long tables with many
(hundreds, or more) entries, may be machine-generated and
not "post-processed" by a human (e.g., unicode/utf8/tables.go).
If a single one of those entries is overlong, the result
would be that the alignment would force all comments or
values in key:value pairs to be adjusted to that overlong
value, making the table hard to read (e.g., that entry may
not even be visible on screen and all other entries seem
spaced out too wide).
Instead, we opted for a slightly improved heuristic that
behaves much better for "normal", human-written code.
1) The threshold is increased from 20 to 40. This disables
the heuristic for many common cases yet even if the alignment
is not "ideal", 40 is not that many characters per line with
todays screens, making it very likely that the entire line
remains "visible" in an editor.
2) Changed the heuristic to not simply look at the size ratio
between current and previous line, but instead considering the
geometric mean of the sizes of the previous (aligned) lines.
This emphasizes the "overall picture" of the previous lines,
rather than a single one (which might be an outlier).
3) Changed the ratio from 4 to 2.5. Now that we ignore sizes
below 40, a ratio of 4 would mean that a new entry would have
to be 4 times bigger (160) or smaller (10) before alignment
would be broken. A ratio of 2.5 seems more sensible.
Applied updated gofmt to all of src and misc. Also tested
against several former issues that complained about this
and verified that the output for the given examples is
satisfactory (added respective test cases).
Some of the files changed because they were not gofmt-ed
in the first place.
For #644.
For #7335.
For #10392.
(and probably more related issues)
Fixes#22852.
Change-Id: I5e48b3d3b157a5cf2d649833b7297b33f43a6f6e
I'm writing a matching implementation of the time package and missed
the "add one day in a leap year" block. This test would have caught my
error.
I understand we can't add test cases for every Date but it seems like
"tripped up someone attempting to reimplement this" is a good
indicator it may trip up people in the future.
Change-Id: I4c3b51e52e269215ec0e52199afe604482326edb
Reviewed-on: https://go-review.googlesource.com/56490
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Round uses r+r < d to decide whether the remainder is
above or below half of d (to decide whether to round up or down).
This is wrong when r+r wraps negative, because it looks < d
but is really > d.
No one will ever care about rounding to a multiple of
d > 2⁶² (about 146 years), but might as well get it right.
Fixes#19807.
Change-Id: I1b55a742dc36e02a7465bc778bf5dd74fe71f7c0
Reviewed-on: https://go-review.googlesource.com/39151
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
1e-9 has a 1 in the last place, causing some Duration calculations to
have unnecessary rounding errors. 1e9 does not, so use that instead.
Change-Id: I96334a2c47e7a014b532eb4b8a3ef9550e7ed057
Reviewed-on: https://go-review.googlesource.com/33116
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In the zero Time, the (not user visible) nil *Location indicates UTC.
In the result of t.UTC() and other ways to create times in specific
zones, UTC is indicated by a non-nil *Location, specifically &utcLoc.
This creates a representation ambiguity exposed by comparison with ==
or reflect.DeepEqual or the like.
Change time.Time representation to use only nil, never &utcLoc,
to represent UTC. This eliminates the ambiguity.
Fixes#15716.
Change-Id: I7dcc2c20ce6b073e1daae323d3e49d17d1d52802
Reviewed-on: https://go-review.googlesource.com/31144
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
AddDate now retrieves location from t.Location() to ensure that
it never calls Date with a nil location.
Added test for this bug on all Time's methods
Fixes#15852
Change-Id: Id2a222af56993f741ad0b802a2c3b89e8e463926
Reviewed-on: https://go-review.googlesource.com/23561
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
The code scanned for an integer after a decimal point, which
meant things could overflow if the number was very precise
(0.1234123412341234123412342134s). This fix changes the
parser to stop adding precision once we run out of bits, rather
than trigger an erroneous overflow.
We could parse durations using floating-point arithmetic,
but since the type is int64 and float64 has only has 53 bits
of precision, that would be imprecise.
Fixes#15011.
Change-Id: If85e22b8f6cef12475e221169bb8f493bb9eb590
Reviewed-on: https://go-review.googlesource.com/29338
Reviewed-by: Costin Chirvasuta <costinc@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There should be a unit, and s is the SI unit name, so use that.
The other obvious possibility is ns (nanosecond), but the fact
that durations are measured in nanoseconds is an internal detail.
Fixes#14058.
Change-Id: Id1f8f3c77088224d9f7cd643778713d5cc3be5d9
Reviewed-on: https://go-review.googlesource.com/22357
Reviewed-by: Robert Griesemer <gri@golang.org>
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The current implementations of MarshalJSON and MarshalText use
time.Format which returns a string (converted from a byte slice),
only to convert it back to a byte slice.
Avoid the conversion (and thus an allocation) by directly appending
the formatted time to a preallocated byte slice, using the new
AppendFormat function, introduced in golang.org/cl/1760.
This reduces the allocations done in Marshal[Text|JSON] by 50%.
benchmark old ns/op new ns/op delta
BenchmarkMarshalJSON 626 507 -19.01%
BenchmarkMarshalText 598 511 -14.55%
benchmark old allocs new allocs delta
BenchmarkMarshalJSON 2 1 -50.00%
BenchmarkMarshalText 2 1 -50.00%
benchmark old bytes new bytes delta
BenchmarkMarshalJSON 96 48 -50.00%
BenchmarkMarshalText 96 48 -50.00%
Fixes#11025
Change-Id: I468f78d075a6ecc1cdc839df7fb407fbc6ff2e70
Reviewed-on: https://go-review.googlesource.com/10555
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.
I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.
Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
Do not lose precision for durations specified without fractions
that can be represented by an int64 such as 1<<53+1 nanoseconds.
Previously there was some precision lost in floating point conversion.
Handle overflow for durations above 1<<63-1 nanoseconds but not earlier.
Add tests to cover the above cases.
Change-Id: I4bcda93cee1673e501ecb6a9eef3914ee29aecd2
Reviewed-on: https://go-review.googlesource.com/2461
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Ian Lance Taylor
Obeyda Djeffal
Shuo
Joe Tsai
Joe Tsai
Michael Darakananda
Derek Phan
Russ Cox
tengufromsky
Kunpei Sakai
fraenkel
Robert Griesemer
Kevin Burke
Caleb Spare
Brad Fitzpatrick
Simon Rawet
Alberto Donizetti
Rob Pike
Josh Bleecher Snyder
Justin Nuß
Martin Möhrmann