proposal: time: export zone and zoneTrans, and add a function to generate a Location

[WhyNotHugo]

What version of Go are you using (go version)?

$ go version
go version go1.17.3 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/hugo/.cache/go-build"
GOENV="/home/hugo/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/hugo/.cache/golang/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/hugo/.cache/golang"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.3"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1388033309=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Trying to create an instance of time.Location based on data read from an iCalendar file.

What did you expect to see?

Some way to construct a time.Location instance.

What did you see instead?

No public function to create such an instance; time.Location instances can only be created with time.LoadLocationFromTZData.

More background

We're trying to parse iCalendar files, which contain VTIMEZONE entries, which represent a timezone (time.Location in go).

However, there's no public function to create time.Location instances, and the only way to create them is using using IANA Time Zone database-formatted data, which is a rather complex binary format.

So currently, the only way to create time.Location entries for the timezones read, is to convert them into the above mentioned binary format, and then feed that into time.LoadLocationFromTZData.

This has two big problems: (1) it's very complex to convert VTIMEZONE data into that binary format, and also, needless complexity (2) it's very inefficient, since every entry read has to be converted into an intermediate representation, to then be parsed again and then converted into the final one.

Making the time.zone and time.zoneTrans public (e.g.: renaming them into time.Zone and time.ZoneTrans, plus adding a time.LocationFromZoneInfo(name string, zones []Zone, zoneTrans []ZoneTrans) Location function would very much help address this issue.

I'd be happy to try and tackle the implementation myself, if the approach seems sound, but I figure it's best to ask for feedback on that first; it's possible that someone has cleaner approaches to solving this issue, or that this breaks some existing convention.

As an alternative approach, a function that takes a string with an RFC-5545 compliant VTIMEZONE and returns a time.Location instance might be a cleaner API, but I'm not sure if adding iCalendar-specific code into this package would be deemed acceptable.

[emetko]

Can't you load the Location from VTIMEZONE.TZID? loc,err := time.LoadLocation(VTIMEZONE.TZID) or if your system does not contain a timezone database you could use the loc := time.FixedZone("locationName", secondsEastOfUTC)

[WhyNotHugo]

Can't you load the Location from VTIMEZONE.TZID? loc,err := time.LoadLocation(VTIMEZONE.TZID)

Regrettably, it's not that simple. This works for components created by some applications, but not all. Looking at my personal calendar, about 30% fail to parse when using this assumption. Some just have a TZID of local, other have the city name in another format, and a few are simply GMT-0300.

Some of the ones that say local include DST transitions too, so they retained the entire local TZ data, without serialising the name.

Aside from the anecdotal data, it's not safe to assume the TZID will match the timezone identifier; from RF5545:

    Note: This document does not define a naming convention for
    time zone identifiers.  Implementers may want to use the naming
    conventions defined in existing time zone specifications such
    as the public-domain TZ database [TZDB].  The specification of
    globally unique time zone identifiers is not addressed by this
    document and is left for future study.

FWIW, this approach you're suggesting is the one we initially took, and that's how we discovered this problem, apologies for not mentioning it initially.

if your system does not contain a timezone database you could use the loc := time.FixedZone("locationName", secondsEastOfUTC)

This won't yield the right results for repeating events (e.g.: a repeating event that repeats every day at 10:00, for a timezone with some DST).

It's also a bit problematic in that de-serialising the data, and the serialising it again would result in some data loss, and if the date for the iCalendar component is changed the timezone needs to be re-read since it's DST data has been lost.

[mknyszek]

CC @ianlancetaylor who seems to have modified this relatively recently.

Maybe this should be a proposal? @WhyNotHugo if you have a particular API in mind that would serve your use-case, then proposing that and having a discussion on that could be fruitful.

[WhyNotHugo]

The Zone and ZoneTrans structs are currently private, and making them public seems like the easiest way to create a public constructor for Location:

Rename the current zone to Zone.
Rename the current zoneTrans to ZoneTrans.

With both structs being publicly usable, add a new method to create a Location instance:

func NewLocationFromZoneData(name string, zones []Zone, zoneTrans []ZoneTrans) Location...

I tried thinking of alternative APIs without using zone and zoneTrans, but they all end up basically re-implementing those two structs, since they represent the minimal amount of data required to create a Location instance.