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 error instead? time.ParseInLocation should always be able to provide something meaningful.
On Monday, February 13, 2023 at 4:13:37 PM UTC+1 Sam Vilain wrote: > > > On Feb 13, 2023, at 9:55 AM, Sven Rebhan <sre...@influxdata.com> 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 that > timezone is in the local timezone? I really wish there would be a way to > handle abbreviations exactly > the same as numeric offsets as the offset to UTC should be known for the > abbreviations, shouldn't they? > > > Yeah, there’s quite a few. The first time I looked at Olson there was > only some overlap between Australia and the US (both claiming “Eastern > Time” as their own territory, which as British Kiwi I found somewhat > amusing). > > CDT could be Cuba (-4) or Central (-5) Daylight Time > EST could be New York (-5) or Sydney (+10) > AST could be Bermuda (-4) or Bahrain (+3) > > See more for yourself on > [image: tadlogo-facebook.png] > > Time Zone Abbreviations - Worldwide List > <https://www.timeanddate.com/time/zones/> > timeanddate.com <https://www.timeanddate.com/time/zones/> > <https://www.timeanddate.com/time/zones/> > > Sam > -- 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/1e2e9e76-ee5d-446c-94bd-53f5896e16f0n%40googlegroups.com.
