Re: [go-nuts] Parsing time with timezones seem to fail

Using location from stamp 2023-02-09 10:55:00 +0100 CET is unix 1675936500 (true) 2023-02-09 02:55:00 -0700 MST is unix 1675936500 (true) Using time.Parse 2023-02-09 10:55:00 + CET is unix 1675940100 (false) 2023-02-09 02:55:00 + MST is unix 1675911300 (false) As reference 2023-02-09 0

Re: [go-nuts] Parsing time with timezones seem to fail

On Mon, Feb 13, 2023 at 7:55 AM 'Thomas Casteleyn' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hi Sam, > > While I do acknowledge there might be some timezones that are ambiguous, > it certainly is not the case for CET and MST. IMHO those should be able to > be correctly parsed by tim

Re: [go-nuts] Parsing time with timezones seem to fail

Hi Sam, While I do acknowledge there might be some timezones that are ambiguous, it certainly is not the case for CET and MST. IMHO those should be able to be correctly parsed by time.Parse and time.ParseInLocation. If provided an ambiguous timezone to time.Parse, that should maybe return an er

Re: [go-nuts] Parsing time with timezones seem to fail

> On Feb 13, 2023, at 9:55 AM, Sven Rebhan wrote: > > I do not yet see where timezone abbreviations are ambiguous... Do you mean > there are multiple timezones with the same abbrev? This is certainly not the > case for MST... > What is the point in taking the timezone into account only if tha

Re: [go-nuts] Parsing time with timezones seem to fail

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) as users potentially query all

Re: [go-nuts] Parsing time with timezones seem to fail

On Friday, February 10, 2023 at 7:45:37 PM UTC+1 Ian Lance Taylor wrote: 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 l

Re: [go-nuts] Parsing time with timezones seem to fail

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'

Re: [go-nuts] Parsing time with timezones seem to fail

On Fri, Feb 10, 2023 at 9:04 AM 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") > mytimeCE

Re: [go-nuts] Parsing time with timezones seem to fail

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

Re: [go-nuts] Parsing time with timezones seem to fail

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, _ = tim

Re: [go-nuts] Parsing time with timezones seem to fail

On Thu, Feb 9, 2023 at 11:26 AM 'Thomas Casteleyn' via golang-nuts 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 con

[go-nuts] Parsing time with timezones seem to fail

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 m