When deleting a timer, a panic due to nil deref
would leave a lock held, possibly leading to a deadlock
in a defer. Instead return false on a nil timer.
Fixes#5745.
R=golang-dev, daniel.morsing, dvyukov, rsc, iant
CC=golang-dev
https://golang.org/cl/10373047
Time is a tiny struct, so the compiler copies a Time by
copying each of the three fields.
The layout of a time on amd64 is [ptr int32 gap32 ptr].
Copying a Time onto a location that formerly held a pointer in the
second word changes only the low 32 bits, creating a different
but still plausible pointer. This confuses the garbage collector
when it appears in argument or result frames.
To avoid this problem, declare nsec as uintptr, so that there is
no gap on amd64 anymore, and therefore no partial pointers.
Note that rearranging the fields to put the int32 last still leaves
a gap - [ptr ptr int32 gap32] - because Time must have a total
size that is ptr-width aligned.
Update #5749
This CL is enough to fix the problem, but we should still do
the other actions listed in the initial report. We're not too far
from completely precise collection.
R=golang-dev, dvyukov, r
CC=golang-dev
https://golang.org/cl/10504043
If time.Sub results in a value that won't fit in a Duration (int64),
return either the min or max int64 value as appropriate.
Fixes#5011.
R=golang-dev, bradfitz, r, rsc
CC=golang-dev
https://golang.org/cl/10328043
undo CL 8478044 / 0d28fd55e721
Lack of consensus.
««« original CL description
time: add Time.FormatAppend
This is a version of Time.Format that doesn't require allocation.
Fixes#5192
Update #5195
R=r
CC=gobot, golang-dev
https://golang.org/cl/8478044
»»»
R=r
CC=golang-dev
https://golang.org/cl/9462049
Change the term 'standard time', which already means something,
to 'reference time', and add a couple of sentences and clarifications.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8799047
* Document Parse's zone interpretation.
* Add ParseInLocation (API change).
* Recognize "wrong" time zone names, like daylight savings time in winter.
* Disambiguate time zone names using offset (like winter EST vs summer EST in Sydney).
The final two are backwards-incompatible changes, but I believe
they are both buggy behavior in the Go 1.0 versions; the old results
were more wrong than the new ones.
Fixes#3604.
Fixes#3653.
Fixes#4001.
R=adg
CC=golang-dev
https://golang.org/cl/7288052
This CL also replaces similar loops in other stdlib
package tests with calls to AllocsPerRun.
Fixes#4461.
R=minux.ma, rsc
CC=golang-dev
https://golang.org/cl/7002055
This fixes the incorrect unix timestamp of the standard time and adds
an example for (Time) Format to clarify how timezones work in format strings.
Fixes#4364.
R=golang-dev, remyoudompheng, kevlar, rsc
CC=golang-dev
https://golang.org/cl/7069046
New in Go 1 will be nanosecond precision in the result of time.Now on Linux.
This will break code that stores time in external formats at microsecond
precision, reads it back, and expects to get exactly the same time.
Code like that can be fixed by using time.Now().Round(time.Microsecond)
instead of time.Now() in those contexts.
R=golang-dev, bradfitz, iant, remyoudompheng
CC=golang-dev
https://golang.org/cl/6903050
The fix for issue 4403 may include more calls to time.Now().UnixNano(). I was concerned that if this function allocated it would cause additional garbage on the heap. It turns out that it doesn't, which is a nice surprise.
Also add benchmark for Now().UnixNano()
R=bradfitz, minux.ma
CC=golang-dev
https://golang.org/cl/6849097
Preparation for forthcoming CL 6624051: Will make it
easier to see if/what changes are incurred by it.
The alignment changes in this CL are due to CL 6610051
(fix to alignment heuristic) where it appears that an
old version of gofmt was run (and thus the correct
alignment updates were not done).
R=r
CC=golang-dev
https://golang.org/cl/6639044
The code was trying to interpret a uint32 n as a signed quantity
and then store it in an int. For this, int(n) currently works, but when
int becomes 64 bits one must write int(int32(n)) instead, to get
the 32-bit sign extension.
Update #2188.
R=golang-dev, nigeltao
CC=golang-dev
https://golang.org/cl/6551068
YearDay provides the day in the year represented by a given time.Time
object. This value is normally computed as part of other date calculations,
but not exported.
Fixes#3932.
R=golang-dev, r, remyoudompheng
CC=golang-dev, rsc
https://golang.org/cl/6460069
The recent shuffle in parsing formats exposed probably unintentional
behavior in time.Parse, namely that it was mostly ignoring ".99999"
in the format, producing the following behavior:
fmt.Println(time.Parse("03:04:05.999 MST", "12:00:00.888 PDT")) // error (.888 unexpected)
fmt.Println(time.Parse("03:04:05.999", "12:00:00")) // error (input too short)
fmt.Println(time.Parse("03:04:05.999 MST", "12:00:00 PDT")) // ok (extra bytes on input make it ok)
http://play.golang.org/p/ESJ1UYXzq2
API CHANGE:
This CL makes all three examples valid: ".999" can match an
empty string or else a fractional second with at most nine digits.
Fixes#3701.
R=r, r
CC=golang-dev
https://golang.org/cl/6267045
When I increased the number of bits that gccgo uses for
untyped floats, the expression 0.52*1e9 was no longer
integral. This patch fixes that.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6113043
I have a small web server that simply sets several cookies
along with an expires header, and then returns. In the
cpuprofile for a 200k request benchmark, time.Time.Format()
was showing up as 8.3% of cpu usage. Giving the buffer an
inital capacity to avoid reallocs on append drops it down to
7.6%.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5992058
For mysterious reasons, the existing string was just wrong: it was missing a colon.
There is no apparent reason for this discrepancy.
This should be safe to fix because existing uses would not be RFC822-compliant;
people cannot be depending on it to generate correct mail headers.
Fixes#3444.
R=golang-dev, dsymonds, iant, rsc
CC=golang-dev
https://golang.org/cl/5969072