On Fri, Feb 10, 2023 at 9:04 AM Sven Rebhan <sreb...@influxdata.com> 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`) 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.
But it's not the case that the timezone abbreviation is never taken into account. As the comment says, the timezone abbreviation is taken into account if it is defined for the current location. For example, if the current location is America/Boise, then MST is meaningful (and so is MDT). if the current location is Europe/Brusselss, then CET is meaningful (and so is CEST among others). This approach is taken because the timezone abbreviations are ambiguous. 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/CAOyqgcU_AQxaU5XkfMRt_RO2doTwjLYOVpQn%3DLNhWvf4B-eWrA%40mail.gmail.com.
