registry.ReadSubKeyNames requires QUERY access right in addition to
ENUMERATE_SUB_KEYS.
This was making TestLocalZoneAbbr fail on Windows 7 in Paris/Madrid
timezone. It succeeded on Windows 8 because timezone name changed from
"Paris/Madrid" to "Romance Standard Time", the latter being matched by
an abbrs entry.
Change-Id: I791287ba9d1b3556246fa4e9e1604a1fbba1f5e6
Reviewed-on: https://go-review.googlesource.com/9809
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Ramp up the delay on subsequent attempts. Fast builders have the same delay.
Not a perfect fix, but should make it better. And this easy.
Fixes#9903 maybe
Fixes#10680 maybe
Change-Id: I967380c2cb8196e6da9a71116961229d37b36335
Reviewed-on: https://go-review.googlesource.com/9795
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
We shouldn't sort the slots array, as it is used each time the
test is run. Tests after the first should continue to use the
unsorted ordering.
Note that this doesn't fix the flaky test. Just a bug I saw
while investigating.
Change-Id: Ic03cca637829d569d50d3a2278d19410d4dedba9
Reviewed-on: https://go-review.googlesource.com/9637
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL copies golang.org/x/sys/windows/registry into
internal/syscall/windows/registry (minus KeyInfo.ModTime to prevent
dependency cycles). New registry package is used in mime and time
packages instead of calling Windows API directly.
Change-Id: I965a5a41d4739b3ba38e539a7b8d96d3223e3d56
Reviewed-on: https://go-review.googlesource.com/9271
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The TestAfterQueueing test is inherently flaky because it relies on
independent kernel threads being scheduled within the "delta" duration
of each other. Normally, delta is 100ms but during "short" testing,
it's reduced to 20ms.
On at least OpenBSD, the CPU scheduler operates in 10ms time slices,
so high system load (e.g., from running multiple Go unit tests in
parallel, as happens during all.bash) can occasionally cause >20ms
scheduling delays and result in test flaking. This manifests as issue
9903, which is the currently the most common OpenBSD flake.
To mitigate this delay, only reduce the delta duration to 20ms for the
first attempt during short testing. If this fails and the test is
reattempted, subsequent attempts instead use a full 100ms delta.
Fixes#9903.
Change-Id: I11bdfa939e5be915f67ffad8a8aef6ed8772159a
Reviewed-on: https://go-review.googlesource.com/9510
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a version of Time.Format that doesn't require allocation.
This is an updated version of 0af302f507
submitted by @bradfitz which was later rolled back.
Fixes#5192
Updates #5195
Change-Id: I4e6255bee1cf3914a6cc8d9d2a881cfeb273c08e
Reviewed-on: https://go-review.googlesource.com/1760
Reviewed-by: Rob Pike <r@golang.org>
Change function appendUint to appendInt with variable-width 0-padding.
This allows the decimal for the year to be generated without extra code
to handle the wider padding and directly handles negative numbers.
Removes the special casing for numbers with one and two digits.
The special case for 0 was unreachable.
The new version is slightly slower.
benchmark old ns/op new ns/op delta
BenchmarkFormat 444 454 +2.25%
BenchmarkFormatNow 398 415 +4.27%
Change-Id: I4ddef96bf07ad35dca76053321d510441ec6d4f5
Reviewed-on: https://go-review.googlesource.com/2751
Reviewed-by: Robert Griesemer <gri@golang.org>
People will still not look at it, but at least we will have a stronger defense.
Change-Id: Ieea6a3d42d06e1067e424e35b87dbcb01c9523cb
Reviewed-on: https://go-review.googlesource.com/7859
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Roll forward of 54efdc596f. Better testing of the build on
darwin/amd64. There is still some variance between cmd/dist
and the Go tool for build tag handling.
Change-Id: I105669ae7f90c8c89b3839c04b182cff46be8dde
Reviewed-on: https://go-review.googlesource.com/6516
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This reverts commit 54efdc596f.
Broken on darwin.
Change-Id: Ic74275f36d30975263340e2b4045226eae71b16a
Reviewed-on: https://go-review.googlesource.com/6514
Reviewed-by: David Crawshaw <crawshaw@golang.org>
A future change will include an NSTimeZone hook so we can determine
the device's current time zone.
Change-Id: Ia4bd6b955e4cb720c518055541b66ff57a4dd303
Reviewed-on: https://go-review.googlesource.com/6511
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Change-Id: I66d923abbef13ba35c76c6f6da5b14c6d534127c
Reviewed-on: https://go-review.googlesource.com/4165
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
If we cannot load timezone information for a reason other than the
zoneinfo file not existing, return it since that will be much more
useful in debugging failures than "unknown time zone XYZ".
Fixes#9723.
Change-Id: I3aa5774859cec28e584d16bcc1fef0705d95288c
Reviewed-on: https://go-review.googlesource.com/3984
Reviewed-by: Ian Lance Taylor <iant@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>
