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+0000"
> 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+0000
> <nil> 2019-02-11 10:38:47 +0000 +0000
> parsed, expected 2019-02-11 10:38:47 +0000 +0000 2019-02-11 10:38:47 +0000
> UTC
> --- FAIL: TestTemp (0.00s)
> tc_test.go:40: 2019-02-11 10:38:47 +0000 +0000 2019-02-11 10:38:47
> +0000 UTC
> FAIL
> exit status 1
> FAIL tc/teamcity 0.042s
>
> So I'm confused, because UTC should be +0000.
> Any other way how to construct the expected day?
>
> po 11. 2. 2019 v 20:52 odesílatel Ian Lance Taylor <ia...@golang.org
> <javascript:>> napsal:
>
>> On Mon, Feb 11, 2019 at 10:53 AM <ste...@gmail.com <javascript:>> 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+0000
>> > <nil>
>> > 2019-02-11 10:38:47 +0000 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-0000"
>> > parsed, err := time.Parse("20060102T150405-0700", date)
>> > fmt.Println(date)
>> > fmt.Println(err)
>> > fmt.Println(parsed)
>> > }
>> >
>> > it outputs
>> >
>> > >go test
>> > 20190211T103847-0000
>> > <nil>
>> > 2019-02-11 10:38:47 +0000 +0000
>> > PASS
>> > ok tc/tcx 0.048s
>> >
>> > Why there is UTC in the first output, but +0000 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 +0000. 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.
