Re: [go-nuts] A Measure of Hash Function Collisions

[Serhat Sevki Dincer]

14 Şub 2019 Per 01:58 tarihinde Michael Jones 
şunu yazdı:

> Serhat,
>
> Some more ideas for you to consider: the expected number of collisions for
> an ideal random hash, the option of "folding in" the high bits of the hash
> rather than truncating, and finer control of operation.
>
> https://play.golang.org/p/92ERC4PJKAL
>

Hi Michael,
Here with your variant:

x = uint64(1<<64-59) ^ uint64(len(s))

for i := len(s) - 1; i >= 0; i-- {
x ^= uint64(s[i])
x *= 11400714819323198549
}

// fold high bits

you have a direct collision with input length's lowest byte (which is
practically the length) and input's first byte. This is better for
initialization:

x = uint64(len(s))
x *= 11400714819323198549

at the cost of an extra multiplication.

Folding high bits does not change collision characteristic, right?
Also when the last operation is a multiplication, you don't seem to need
it, if at all it is useful.

>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] What is the future of go mod vendoring?

[Paul A. Fortin]

I have heard that the vendir dirctory is here to stay and also that it is 
going away - can someone from the goteam give us a idea of the future of 
that feature?

Thanks

p4tin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go - logo commercial use

[Space A.]

That means that must give credit to author (Renee French)
AND
you must give credit to license itself


All CC licenses require users to attribute the creator of licensed 
material, unless the creator has waived that requirement 
, 
not supplied a name, or asked that her name be removed 
.
 
Additionally, you must retain a copyright notice, a link to the license (or 
to the deed), a license notice, a notice about the disclaimer of 
warranties, and a URI if reasonable. For versions prior to 4.0, you must 
also provide the title of the work. (Though it is not a requirement in 4.0, 
it is still recommended if one is supplied.)

You must also indicate if you have modified the work 
—for
 
example, if you have taken an excerpt, or cropped a photo. (For versions 
prior to 4.0, this is only required if you have created an adaptation by 
contributing your own creative material, but it is recommended even when 
not required.) It is not necessary to note trivial alterations, such as 
correcting a typo or changing a font size. Finally, you must retain an 
indication of previous modifications to the work.

here -> https://creativecommons.org/faq/

четверг, 14 февраля 2019 г., 2:18:04 UTC+3 пользователь Ian Lance Taylor 
написал:
>
> On Wed, Feb 13, 2019 at 3:15 PM > wrote: 
> > 
> > I would love to be able to include your logo as part of our inventory 
> (sticker site) but aren’t sure of the restrictions regarding its use for 
> commercial purposes, so we would like to find out what your policy is 
> regarding this and if this would be a possibility? 
> > 
> > We do not plan to modify or alter the logo in any way or claim that it 
> is ours. To get a better idea of how we plan to use the logo, please see 
> the following website, as this is very similar to what we plan to do: 
> https://www.stickermule.com/ 
>
> Quoting from https://blog.golang.org/gopher: 
>
> The gopher images are Creative Commons Attribution 3.0 licensed. That 
> means you can play with the images but you must give credit to their 
> creator (Renee French) wherever they are used. 
>
> Thanks for asking. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go - logo commercial use

[Ian Lance Taylor]

On Wed, Feb 13, 2019 at 3:15 PM  wrote:
>
> I would love to be able to include your logo as part of our inventory 
> (sticker site) but aren’t sure of the restrictions regarding its use for 
> commercial purposes, so we would like to find out what your policy is 
> regarding this and if this would be a possibility?
>
> We do not plan to modify or alter the logo in any way or claim that it is 
> ours. To get a better idea of how we plan to use the logo, please see the 
> following website, as this is very similar to what we plan to do: 
> https://www.stickermule.com/

Quoting from https://blog.golang.org/gopher:

The gopher images are Creative Commons Attribution 3.0 licensed. That
means you can play with the images but you must give credit to their
creator (Renee French) wherever they are used.

Thanks for asking.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go - logo commercial use

[agaborcz86]

I would love to be able to include your logo as part of our inventory 
(sticker site) but aren’t sure of the restrictions regarding its use for 
commercial purposes, so we would like to find out what your policy is 
regarding this and if this would be a possibility?

We do not plan to modify or alter the logo in any way or claim that it is 
ours. To get a better idea of how we plan to use the logo, please see the 
following website, as this is very similar to what we plan to do: 
https://www.stickermule.com/ 

Thank you for looking up for me

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A Measure of Hash Function Collisions

[Michael Jones]

Serhat,

Some more ideas for you to consider: the expected number of collisions for
an ideal random hash, the option of "folding in" the high bits of the hash
rather than truncating, and finer control of operation.

https://play.golang.org/p/92ERC4PJKAL

On Wed, Feb 13, 2019 at 12:20 PM Serhat Şevki Dinçer 
wrote:

> On Tuesday, February 12, 2019 at 9:51:17 PM UTC+3, Michael Jones wrote:
>>
>> Serhat, some ideas for you...
>> https://play.golang.org/p/7QPy5wa-9eO
>>
>
> Interestingly I found out input iteration order does matter :) 15,33 shift
> version yields an amazing number of collisions (7_910_886_368 collisions
> over 7_918_845_952 inputs) when fed with a spesific 6-byte sequence
> (attached).
> rotate-27 version interestingly gave no collisions for this case. prime
> version also had no collisions. prime version with ^= and -= instead of +=
> also gave no collision.
>
> I want to identify a collision on the prime version (any variant ^= -= +=)
> with small inputs, say sum of lengths <= 12. Does anyone have any idea how
> to identify such inputs?
> So far prime version seems to be the most promising (in terms of high
> minimum sum of collding inputs)..
>
> Thanks..
>
> Note: Thanks Damian, it looks like an advanced test suite for cryto
> hashes, though text input tests seems limited.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A Measure of Hash Function Collisions

[Serhat Şevki Dinçer]

On Tuesday, February 12, 2019 at 9:51:17 PM UTC+3, Michael Jones wrote:
>
> Serhat, some ideas for you...
> https://play.golang.org/p/7QPy5wa-9eO
>

Interestingly I found out input iteration order does matter :) 15,33 shift 
version yields an amazing number of collisions (7_910_886_368 collisions 
over 7_918_845_952 inputs) when fed with a spesific 6-byte sequence 
(attached).
rotate-27 version interestingly gave no collisions for this case. prime 
version also had no collisions. prime version with ^= and -= instead of += 
also gave no collision.

I want to identify a collision on the prime version (any variant ^= -= +=) 
with small inputs, say sum of lengths <= 12. Does anyone have any idea how 
to identify such inputs?
So far prime version seems to be the most promising (in terms of high 
minimum sum of collding inputs)..

Thanks..

Note: Thanks Damian, it looks like an advanced test suite for cryto hashes, 
though text input tests seems limited.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


txt2int3.go
Description: Binary data

[go-nuts] Re: bulding pipelines in golang

[clementauger888]

hi,

in recent days i have been working on fixing some issues with above 
presented code 
(https://github.com/clementauger/st/blob/master/examples/walkfiles/main.go#L38)
besides the fact the internal code uses a lot of reflection mechanisms to 
implement the api, putting in de facto on the wrong side of the performance 
line.
there was a bunch of memory management on the user land side that could be 
improved.

for example, that stage 
https://github.com/clementauger/st/blob/master/examples/walkfiles/main.go#L68 
creates as many slices as input batch to process.
see also line 70 71 72.

to quickly take a look to the given solution open  
https://github.com/clementauger/st/blob/master/examples/walkfiles/main5.go#L51

You will find the usage of sync.Pool coupled to two new kind of stages 
PoolBuffered L53 and PoolRecycler L62 
they take care of allocations/recyclings performed in order to pass in and 
out a routine context L58 by accumulating or consuming values of containers 
such as slices. 
this solves lines 68 and 70 of the original demonstration code.

You will also find the introduction of self-contained function within the 
Concurrently call L58. 
those functions returns the iterable function instead of being it. They can 
also return instances of st.Mapper directly, as demonstrated.
this helps to solve lines 71 and 72 of the original demonstration code.
in an earlier version, this problem was handled with a sync.Pool 
(https://github.com/clementauger/st/blob/master/examples/walkfiles/main3.go#L69)
However, this is not the best solution available.
because those self-contained functions are executed once for each worker,  
they can allocate on their own routine at beginning without needing of 
synchronization.

ftr, i have kept several versions i have edited since the original i posted 
in the previous email,
https://github.com/clementauger/st/blob/master/examples/walkfiles/main.go
https://github.com/clementauger/st/blob/master/examples/walkfiles/main1.go
etc...
https://github.com/clementauger/st/blob/master/examples/walkfiles/main5.go

finally, note that the last commit is a major change as it breaks the 
Mapper interface.
its not yet tagged, it will happen later.

I am searching for ideas about how i could get ride of the use of reflect 
package.
static analysis can not work.
dynamic go code generation did not work, might work, seems difficult.
any idea is welcome.

thanks for reading.

Hi,
>
> I recently confronted the problem of building data stream pipeline in 
> golang to build some etl programs.
>
> I found it was not so simple to use the golang idioms.
> Using them i noticed i needed deep care and understanding to produce 
> correct code.
> I also felt they was uselessly verbose and repetitive.
>
> I have searched for existing libraries produced by the community 
> but I failed to find a suitable one for my need.
> Something like ratchet (https://github.com/dailyburn/ratchet) was close 
> to it, 
> but its unlikely i use such complex api.
>
> I came to write my own for this purpose, 
> you can find it here https://github.com/clementauger/st
>
> To achieve it i have been extensively using the reflection API, which is 
> really helpful.
> Unfortunately, I have been using interface{} almost everywhere, and that 
> would be difficult to change.
> In exchange this api provides lots of flexibility.
>
> For comparison and introduction purposes i have rewrote the pipeline walk 
> file example
> available in the blog at https://blog.golang.org/pipelines
>
> The version i provide is available at
> https://github.com/clementauger/st/blob/master/examples/walkfiles/main.go
>
> This version implements a slightly more complex flow mecanism as it 
> bufferizes path, 
> however, it is much easier, shorter (<150 LOC), and i believe clearer code 
> than the original version.
> Where the last property is subject to personal opinion, yet, I encourage 
> you to consider it.
>
> Overall, while this implementation is slower because there are tons of 
> additionnal indirections,
> I think it is still interesting to consider to compensate that 
> with easier and appropriate bufferization and paralellisation whenever 
> possible
> to achieve better performance.
> I intended that this library helps to make that happens as easily and 
> smoothly as possible.
>
> For your information you can also find a bulk version 
> of the original bounded version provided in the blog 
> at 
> https://github.com/clementauger/x/blob/master/01_pipeline/bounded_bulk.go.
> This last program is more suitable for full comparison with the version i 
> provide.
>
> I hope to engage in interesting conversations around that,
> thanks for reading.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [golang-dev] database/sql changes and proposals

[Brad Fitzpatrick]

Thanks for setting this up!


On Tue, Feb 12, 2019 at 4:33 PM Daniel Theophanes 
wrote:

> In order to help keep database/sql driver developers and the maintainers
> of database/sql on the same page, I'm going to start to posting issues and
> proposals to the following group:
>
> https://groups.google.com/forum/#!forum/golang-sql
>
> If you are a driver developer, I would recommend subscribing to it (if you
> aren't already).
>
> Thanks, -Daniel
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] tool to automatically refresh godoc ?

[Sebastien Binet]

On Sat, Dec 22, 2018 at 2:15 AM Dan Kortschak  wrote:

> And yes. The curl option is -d, not -F, so
>
> curl -X POST -d "path=${IMPORTPATH}" https://godoc.org/-/refresh
>
> works and could easily be made into a post-push hook to be run in the
> root of the package like so:
>
> for pkg in $(go list ./...); do
> curl -X POST -d "path=${pkg}" https://godoc.org/-/refresh
> done
>

FYI, I've translated this to:
 https://github.com/go-hep/hep/blob/master/ci/update-godoc.go

thanks!

-s

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: View http open connections

[Kevin Conway]

> Does anyone know a way of getting current open connections?

You might consider using https://golang.org/pkg/net/http/#Server.ConnState
for this instead of a middleware for the http.Handler. The different
connection states are documented on
https://golang.org/pkg/net/http/#ConnState and the callback should fire
each time a connection changes state (including new and closed). This
should also help distinguish between connections which are not really the
same as active requests.

On Wed, Feb 13, 2019 at 7:54 AM Dany Xu 
wrote:

> what does it means "heavy load"? if not in "heavy load", it can work ? On
> the other hand, do you want the tcp connections or the http req numbers?
> From the go package, it appears that getting the basic tcp connections in
> http.server is impossible.
>
> 在 2019年2月12日星期二 UTC+8下午10:37:52，jose.albe...@gmail.com写道：
>>
>> I was trying to get current HTTP connections in HTTP.Server. Internally
>> transport tracks it under connPerHostCount. However, I don't see a way of
>> getting this value.
>>
>> I tried this:
>>
>> type HTTPRequestMetrics struct {
>>  activeConnections int64
>>  next  http.Handler
>> }
>>
>>
>> func HTTPRequestMetricsHandler(h http.Handler) *HTTPRequestMetrics {
>>  return {next: h}
>> }
>>
>>
>> func (h *HTTPRequestMetrics) ServeHTTP(w http.ResponseWriter, r *http.
>> Request) {
>>  atomic.AddInt64(, 1)
>>  defer atomic.AddInt64(, -1)
>>
>>
>>  h.next.ServeHTTP(w, r)
>> }
>>
>>
>> But looks like defer never gets called when under heavy load (and clients
>> see connection reset by peer)
>>
>> Does anyone know a way of getting current open connections?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Kevin Conway

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: View http open connections

[Dany Xu]

what does it means "heavy load"? if not in "heavy load", it can work ? On 
the other hand, do you want the tcp connections or the http req numbers? 
>From the go package, it appears that getting the basic tcp connections in 
http.server is impossible. 

在 2019年2月12日星期二 UTC+8下午10:37:52，jose.albe...@gmail.com写道：
>
> I was trying to get current HTTP connections in HTTP.Server. Internally 
> transport tracks it under connPerHostCount. However, I don't see a way of 
> getting this value.
>
> I tried this:
>
> type HTTPRequestMetrics struct {
>  activeConnections int64
>  next  http.Handler
> }
>
>
> func HTTPRequestMetricsHandler(h http.Handler) *HTTPRequestMetrics {
>  return {next: h}
> }
>
>
> func (h *HTTPRequestMetrics) ServeHTTP(w http.ResponseWriter, r *http.
> Request) {
>  atomic.AddInt64(, 1)
>  defer atomic.AddInt64(, -1)
>
>
>  h.next.ServeHTTP(w, r)
> }
>
>
> But looks like defer never gets called when under heavy load (and clients 
> see connection reset by peer)
>
> Does anyone know a way of getting current open connections?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Handling connection retries on a highly-available service

[Dany Xu]

As discuss above, i think the answer is decoupling the P and logger, 
storing the logs when the logger is down.The push and pull pattern would be 
better.The p sends all logs and the logger pulls all logs.Just keep a 
bigger storage for un-consumed logs.Queue may be is a better way but using 
a single storage.

在 2019年2月12日星期二 UTC+8上午12:34:46，Michel Levieux写道：
>
> Hi guys. I need a little help here.
>
> I work in a digital marketing company, where we have a program that 
> receives a lot of requests every second (counted in thousands) and logs its 
> behaviour via a logger that runs on another server. We are currently trying 
> to implement a connection-retry system between this program and its logging 
> API. What we want is :
>
> - We have a main program - let's call it P
> - P sends logs to the logger in multiple goroutines.
> - Sometimes we might need to shut down the logger (for maintenance or 
> anything)
> - We want P to keep running when the logger's down
> - Once the logger's up again, P must Dial it back automatically and repair 
> the *bufio.Writer associated with it
>
> Would you guys know a way not to check each single Read/Write if the 
> logger's up?
>
> Up to here we have thought of using atomic, mutexes and context for 
> synchronization, but the issues we face are the following:
>
> - mutexes create "pending" requests, since there's no way to check if a 
> mutex is locked or not
> - we're not really sure about the right way to use context for this 
> specific case
> - we'd like to avoid using atomics as much as possible, notably about this 
> quote from the docs : "*Except for special, low-level applications, 
> synchronization is better done with channels or the facilities of the sync 
> package*"
>
> In the end, what we're looking for is to reach a minimal checking 
> frequency (is connection up? do something, else do nothing), the ideal 
> being not to have to check anything.
>
> Have you guys already faced such problematics in the past? What solutions 
> have you come up with?
>
> Many thx in advance for your help!
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Parsing date with Timezone doesn't return UTC

[Volker Dobler]

There are several issues here.

1. If you use fmt.Println to display a time.Time it will generate a
human readable output but this does _not_ accurately reflect all
technical internal details of a time.Time. It is often a bad idea to
simply dump stuff with fmt.Println.

2. time.Parse and timezones is complicated. Carefully read the
last three paragraphs of time.Parse's documentation. You'll see
that what you try to do has a big chance of not working.

3. If you want to compare two time.Time use time.Time.Equal
which is designed to handle differences, even technical) in location.

4. If you want a time.Time to be in a certain location (e.g. UTC)
use time.Time.UTC or time.Time.In. Afterwards you might be able
to use == on them.

5. You parsed time has a numeric timezone with offset 0.
That is logically equivalent to timezone UTC and the Equal method would
report them to be the same instant but as time.Time these two
things are technically different: One has timezone UTC and the other
one (probably!) a "fabricated location".

V.

On Wednesday, 13 February 2019 09:18:36 UTC+1, Pepa Štefan wrote:
>
> Thank you for answering me. That makes sense. 
> The reason why I noticed that was because I have a test and wanted to 
> ensure that the time is properly parsed. But I can't construct the expected 
> value. 
>
> Imagine this test: 
>
> func TestTemp(t *testing.T) {
> toTest := "20190211T103847+"
> parsed, err := time.Parse("20060102T150405-0700", toTest)
> expected := time.Date(2019, time.Month(2), 11, 10, 38, 47, 0, 
> time.UTC)
> fmt.Println(toTest)
> fmt.Println(err, parsed)
> fmt.Println("parsed, expected", parsed, expected)
> if parsed != expected {
> t.Error(parsed, expected)
> }
> }
>
> This outputs
> >go test
> 20190211T103847+
>  2019-02-11 10:38:47 + +
> parsed, expected 2019-02-11 10:38:47 + + 2019-02-11 10:38:47 + 
> UTC
> --- FAIL: TestTemp (0.00s)
> tc_test.go:40: 2019-02-11 10:38:47 + + 2019-02-11 10:38:47 
> + UTC
> FAIL
> exit status 1
> FAILtc/teamcity 0.042s
>
> So I'm confused, because UTC should be +.
> Any other way how to construct the expected day?
>
> po 11. 2. 2019 v 20:52 odesílatel Ian Lance Taylor  > napsal:
>
>> On Mon, Feb 11, 2019 at 10:53 AM > wrote:
>> >
>> > Hi all, please could you help me with a simple problem?
>> >
>> > I have some parsing code like this: 
>> https://play.golang.org/p/6bVyWg4FCVN
>> >
>> > It writes
>> >
>> > 20190211T103847+
>> > 
>> > 2019-02-11 10:38:47 + UTC
>> >
>> >
>> > on the server.
>> >
>> > When I put the code into test,
>> >
>> > package tcx_test
>> >
>> > import (
>> > "fmt"
>> > "testing"
>> > "time"
>> > )
>> >
>> > func TestTemp(t *testing.T) {
>> > date := "20190211T103847-"
>> > parsed, err := time.Parse("20060102T150405-0700", date)
>> > fmt.Println(date)
>> > fmt.Println(err)
>> > fmt.Println(parsed)
>> > }
>> >
>> > it outputs
>> >
>> > >go test
>> > 20190211T103847-
>> > 
>> > 2019-02-11 10:38:47 + +
>> > PASS
>> > ok  tc/tcx 0.048s
>> >
>> > Why there is UTC in the first output, but + in the second one?
>>
>> It depends on the timezone information available on the system and on
>> the system's local time zone.  If the system's local time zone is UTC,
>> that will be used.  Otherwise, the time will use an unnamed timezone
>> at offset +.  That winds up with the difference that you see.  See
>> the docs for time.Parse:
>>
>> When parsing a time with a zone offset like -0700, if the offset
>> corresponds to a time zone used by the current location (Local), then
>> Parse uses that location and zone in the returned time. Otherwise it
>> records the time as being in a fabricated location with time fixed at
>> the given zone offset.
>>
>> Ian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Parsing date with Timezone doesn't return UTC

[Pepa]

Thank you for answering me. That makes sense.
The reason why I noticed that was because I have a test and wanted to
ensure that the time is properly parsed. But I can't construct the expected
value.

Imagine this test:

func TestTemp(t *testing.T) {
toTest := "20190211T103847+"
parsed, err := time.Parse("20060102T150405-0700", toTest)
expected := time.Date(2019, time.Month(2), 11, 10, 38, 47, 0, time.UTC)
fmt.Println(toTest)
fmt.Println(err, parsed)
fmt.Println("parsed, expected", parsed, expected)
if parsed != expected {
t.Error(parsed, expected)
}
}

This outputs
>go test
20190211T103847+
 2019-02-11 10:38:47 + +
parsed, expected 2019-02-11 10:38:47 + + 2019-02-11 10:38:47 +
UTC
--- FAIL: TestTemp (0.00s)
tc_test.go:40: 2019-02-11 10:38:47 + + 2019-02-11 10:38:47
+ UTC
FAIL
exit status 1
FAILtc/teamcity 0.042s

So I'm confused, because UTC should be +.
Any other way how to construct the expected day?

po 11. 2. 2019 v 20:52 odesílatel Ian Lance Taylor  napsal:

> On Mon, Feb 11, 2019 at 10:53 AM  wrote:
> >
> > Hi all, please could you help me with a simple problem?
> >
> > I have some parsing code like this:
> https://play.golang.org/p/6bVyWg4FCVN
> >
> > It writes
> >
> > 20190211T103847+
> > 
> > 2019-02-11 10:38:47 + UTC
> >
> >
> > on the server.
> >
> > When I put the code into test,
> >
> > package tcx_test
> >
> > import (
> > "fmt"
> > "testing"
> > "time"
> > )
> >
> > func TestTemp(t *testing.T) {
> > date := "20190211T103847-"
> > parsed, err := time.Parse("20060102T150405-0700", date)
> > fmt.Println(date)
> > fmt.Println(err)
> > fmt.Println(parsed)
> > }
> >
> > it outputs
> >
> > >go test
> > 20190211T103847-
> > 
> > 2019-02-11 10:38:47 + +
> > PASS
> > ok  tc/tcx 0.048s
> >
> > Why there is UTC in the first output, but + in the second one?
>
> It depends on the timezone information available on the system and on
> the system's local time zone.  If the system's local time zone is UTC,
> that will be used.  Otherwise, the time will use an unnamed timezone
> at offset +.  That winds up with the difference that you see.  See
> the docs for time.Parse:
>
> When parsing a time with a zone offset like -0700, if the offset
> corresponds to a time zone used by the current location (Local), then
> Parse uses that location and zone in the returned time. Otherwise it
> records the time as being in a fabricated location with time fixed at
> the given zone offset.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.