Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: time: List timezones #20211
I'd like to propose to add a function to the time package that lists the set of installed timezones. For a good user experience, I want my service to provide auto completion or a drop-down for a user to select their timezone; currently, the time package only supports probing, which would make for a bad user-experience.
In theory, this could be provided outside of the stdlib by walking the corresponding directory trees; however, for different systems, different directories are used, so this would require duplicating those lists and keeping them in sync with the stdlib manually (otherwise you might claim to support a timezone, which you then not actually support; again, a bad user experience).
I'd write this myself, but wanted to first get an opinion on whether this would be accepted.
Someone would have to put readdir etc into package time (which cannot import os), at the bare minimum. Then the implementation would have to read the TZ database directory and open and read every file? Or maybe just list them and let the caller open them?
It's true that package time knows best where it will search from LoadLocation, and returning the directory is not super-helpful on Windows or other systems that have it in the zip file in GOROOT. So you can't write this function outside the standard library.
On the other hand it seems very specialized.
I did not think about the restrictions about importing packages; that, indeed, complicates things and changes the tradeoffs significantly. TBH, I don't find it that specialized. I'd argue that most software that exposes timezones to users probably wants this, or risk being very frustrating to users. I know I often don't know what to call the timezone I'm about; what major city to use (and daylight savings time makes zone abbreviations pretty useless too, AIUI). But yeah, I can see how it's probably specialized enough to not justify the tradeoffs under these circumstances.
I'd still love to see this (maybe in x/, which doesn't have the restriction on imports but would still have reasonable guarantees to stay in sync with the stdlib?), but understand if you decide to not do it.