Hey Jason E. Aten, while I fully agree that using abbreviations is suboptimal, we have to deal with them in projects like influxdata/telegraf: The plugin-driven server agent for collecting & reporting metrics. (github.com) <https://github.com/influxdata/telegraf> as users potentially query all sort of services outside our responsibility. Those services do weird things like sending timestamps with timezone abbreviations. ;-)
The current behavior of `time.Parse` is very cumbersome as we probably always need to work-around it by stamp, _ := time.Parse(layout, v) loc, _ := time.LoadLocation(stamp.Location().String()) stamp, _ = time.ParseInLocation(layout, v, loc) while I would expect that parsing `"2023-02-09 02:55:00 MST"` with `time.Parse` would return the correct time located in UTC.... And I don't see how that time is ambiguous. Sorry. On Saturday, February 11, 2023 at 3:05:53 PM UTC+1 Jason E. Aten wrote: > 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/809e7d24-0786-4889-8ac2-d342d7826a25n%40googlegroups.com.
