Closed rgerardi closed 1 year ago
Even the example from the book doesn't work on my system:
$ go run convertTimes.go "14 December 2023 19:20 EET"
2023-12-14 19:20:00 +0000 EET
Current Location: 2023-12-14 14:20:00 -0500 EST
New York Time: 2023-12-14 14:20:00 -0500 EST
LA Time: 2023-12-14 11:20:00 -0800 PST
London Time: 2023-12-14 19:20:00 +0000 GMT
Tokyo Time: 2023-12-15 04:20:00 +0900 JST
This is strange – go run convertTimes.go "14 December 2023 19:20 EET"
command worked OK on my system:
Current Location: 2023-12-14 19:20:00 +0200 EET
New York Time: 2023-12-14 12:20:00 -0500 EST
London Time: 2023-12-14 17:20:00 +0000 GMT
Tokyo Time: 2023-12-15 02:20:00 +0900 JST
This is very strange. I ran it on 2 different machines and I get the same wrong results on both. Both machines run Linux, one is Archlinux, the other is Fedora 38.
I also ran it in a container using the official Go image and I got the same wrong results. Tested both Go 1.20 and Go 1.21
This is on a Linux machine:
$ go run convertTimes.go "14 December 2023 19:20 EET"
Current Location: 2023-12-14 19:20:00 +0200 EET
New York Time: 2023-12-14 12:20:00 -0500 EST
London Time: 2023-12-14 17:20:00 +0000 GMT
Tokyo Time: 2023-12-15 02:20:00 +0900 JST
$ uname -a
Linux thinkpad 6.5.6-arch2-1 #1 SMP PREEMPT_DYNAMIC Sat, 07 Oct 2023 08:14:55 +0000 x86_64 GNU/Linux
Can you please run a git pull
to make sure that you have the latest version?
So strange. I just updated my Archlinux and ran a git pull
. Still, same results:
$ git pull
Already up to date.
$ go run convertTimes.go "14 December 2023 19:20 EET"
Current Location: 2023-12-14 14:20:00 -0500 EST
New York Time: 2023-12-14 14:20:00 -0500 EST
London Time: 2023-12-14 19:20:00 +0000 GMT
Tokyo Time: 2023-12-15 04:20:00 +0900 JST
$ uname -a
Linux vader 6.5.6-arch2-1 #1 SMP PREEMPT_DYNAMIC Sat, 07 Oct 2023 08:14:55 +0000 x86_64 GNU/Linux
$ go version
go version go1.21.1 linux/amd64
Running on a Thinkpad T14
On a different Arch Linux machine, I got the following:
$ go run convertTimes.go "14 December 2023 19:20 EET"
Current Location: 2023-12-14 19:20:00 +0200 EET
New York Time: 2023-12-14 12:20:00 -0500 EST
London Time: 2023-12-14 17:20:00 +0000 GMT
Tokyo Time: 2023-12-15 02:20:00 +0900 JST
Maybe it is because we live at different locations. I cannot think of anything else.
This is too weird. And the code looks good to me but I keep getting the wrong results, no matter where I run it. More examples:
Fedora 38 Virtual Machine, running on Dell server KVM hypervisor:
$ go run convertTimes.go "14 December 2023 19:20 EET"
Current Location: 2023-12-14 14:20:00 -0500 EST
New York Time: 2023-12-14 14:20:00 -0500 EST
London Time: 2023-12-14 19:20:00 +0000 GMT
Tokyo Time: 2023-12-15 04:20:00 +0900 JST
$ uname -a
Linux f38scrc01 6.5.5-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Sep 24 15:52:44 UTC 2023 x86_64 GNU/Linux
$ go version
go version go1.20.8 linux/amd64
Containers:
$ podman run -v $(pwd):/scripts docker.io/library/golang:1.21 go run /scripts/convertTimes.go "14 December 2023 19:20 EET"
Current Location: 2023-12-14 19:20:00 +0000 UTC
New York Time: 2023-12-14 14:20:00 -0500 EST
London Time: 2023-12-14 19:20:00 +0000 GMT
Tokyo Time: 2023-12-15 04:20:00 +0900 JST
$ podman run -v $(pwd):/scripts docker.io/library/golang:1.20 go run /scripts/convertTimes.go "14 December 2023 19:20 EET"
Current Location: 2023-12-14 19:20:00 +0000 UTC
New York Time: 2023-12-14 14:20:00 -0500 EST
London Time: 2023-12-14 19:20:00 +0000 GMT
Tokyo Time: 2023-12-15 04:20:00 +0900 JST
It seems to be a known Go issue: https://github.com/golang/go/issues/63345
Thanks for pointing that out! Closing the issue.
convertTimes.go
from ch02 not parsing all time zones correctly.I have not yet figured out if it's a bug with Go or something on my system but I wanted to report so you can also take a look.
For example, when I execute this program providing an input with time zones MDT, MST, PDT, or PST, it parses them as UTC. To test, I added another location for PDT time zone to check and the times should match but don't.
Example output:
but if I use EDT instead, it works:
I also noticed that using an inexisting time zone, it also parses it as UTC: