I'll add more strongly proscriptive advice on dealing with timestamps. Personally I hate code that will do different things depending on where in the world (which computer, different notion of "Local") it is run on. It makes reproducing issues hellish/very hard. So I strongly recommend:
1. Don't use ambiguous timezone indications like MST in your timestamps, use numerical offsets from UTC, like -0700 instead. 2. Always have a numerical timezone offset on your timestamp, never leave it blank. 3. If you have to deal with a blank timezone, because some idiot has failed follow rules 1 and 2, that is the only time you should be using time.ParseInLocation(). 4. Otherwise, you should be using time.Parse(), with your numerical offset in the string being parsed. This means use a format like const layoutTZ = "2006-01-02 15:04:05 -0700" These rules will make your life dealing with timezones in timestamps sane. Given those guidelines, there are two ways of dealing with the ambiguous (poor, bad idea) timestamp "2023-02-09 02:55:00 MST". These are both illustrated here https://go.dev/play/p/0dU7an_bctP a. Truncate off the ambiguous timezone indication, and then use ParseInLocation while supplying a location like America/Denver: denver, err := time.LoadLocation("America/Denver") panicOn(err) testParseLocation("2023-02-09 02:55:00", denver) b. Replace the ambiguity with an unambiguous numerical offset before parsing: testParse("2023-02-09 02:55:00 -0700") On Friday, February 10, 2023 at 11:04:15 AM UTC-6 Sven Rebhan wrote: > The issue here is that the timezone information is ignored when computing > the timestamp *value.* Take the following examples > > layout := "2006-01-02 15:04:05 MST" > mytimeMST, err := time.Parse(layout, "2023-02-09 02:55:00 MST") > mytimeCET, err := time.Parse(layout, "2023-02-09 10:55:00 CET") > > Both `mytimeMST` *and* `mytimeCET` refer to the exactly same > point-in-time (i.e. 2023-02-09 09:55:00 UTC) with Unix timestamp > 1675936500. However, when you run the code (see playground example) the > result is > > mytimeMST: 2023-02-09 02:55:00 +0000 MST which is timestamp > 1675911300 > mytimeCET: 2023-02-09 10:55:00 +0000 CET which is timestamp > 1675940100 > > This is totally unexpected as, according to the documentation of > `time.Parse` > > > *When parsing a time with a zone abbreviation like MST, if the zone > abbreviation has a defined offset in the current location, then that offset > is used. The zone abbreviation "UTC" is recognized as UTC regardless of > location. If the zone abbreviation is unknown, Parse records the time as > being in a fabricated location with the given zone abbreviation and a zero > offset. [...]* > Obviously, the `time.Parse` function treats *MST *and *CET* as *unknown* > abbreviations, > however, when using those abbrevs in > other locations (e.g. in `time.LoadLocation > <https://cs.opensource.google/go/go/+/go1.20:src/time/zoneinfo.go;l=662>`) > they are perfectly known with a defined offset in the current location. > > So my expectation (and I guess also Thomas') would be that both > `mytimeMST` and `mytimeCET` result in timestamp 1675936500! > Either this or clarify the documentation that the timezone abbrev is > *never* taken into account and had to be manually treated. > > Best regards, > > Sven > > On Friday, February 10, 2023 at 9:37:03 AM UTC+1 Thomas Casteleyn wrote: > >> Being able to parse these timestamps correctly and produce correct Unix >> time from them; >> >> Together with the Gophers slack, we found this ugly, but working hack: >> https://go.dev/play/p/nG-M0pUrm0Z >> stamp, _ := time.Parse(layout, v) >> loc, _ := time.LoadLocation(stamp.Location().String()) >> stamp, _ = time.ParseInLocation(layout, v, loc) >> >> glibc is doing this better IMHO. >> >> On Thursday, February 9, 2023 at 8:47:52 PM UTC+1 Ian Lance Taylor wrote: >> >>> On Thu, Feb 9, 2023 at 11:26 AM 'Thomas Casteleyn' via golang-nuts >>> <golan...@googlegroups.com> wrote: >>> > >>> > Hi, I originally asked on Gophers slack where they directed me to this >>> group. >>> > >>> > It seems I'm not able to parse these 2 timestamps with timezone >>> correctly: https://go.dev/play/p/VZwD29701ps >>> > >>> > The responses show confusing time formats and the playground even >>> seems to be more wrong than on my local machine. >>> > >>> > How should I correctly parse both timestamps in Go? >>> >>> It's not clear to me what you are actually trying to do. >>> ParseInLocation will look for a timezone name like CET or MST relative >>> to the location that you give it. This approach is used because >>> identifiers like CET or MST are ambiguous. So in general it's odd to >>> use ParseInLocation with an arbitrary timezone identifier. What is >>> your actual goal? >>> >>> 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0ae192ea-d1d2-437a-a2e9-40cc97532b88n%40googlegroups.com.
