New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: time: List timezones #20211
Comments
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. |
Related issue: #20629 ("time: Add function to generate a Location struct") |
Will close this in favor of #20629. |
I'm not sure that's possible with the eventually chosen solution to #20629, is it? The tzdata package doesn't seem to provide any way to acquire any of the actual data or enumerate the possible locations. Should this issue be reopened, or am I missing something? |
As far as I can see basically the only thing people need to implement this is the list of directories, which on Unix systems is: "/usr/share/zoneinfo/",
"/usr/share/lib/zoneinfo/",
"/usr/lib/locale/TZ/",
runtime.GOROOT() + "/lib/time/zoneinfo.zip", I think the question is: is it useful for the time package to export that list? |
That's not quite true, at least any more, because the data can also be in the tzdata package. I see the problem with adding directory-reading functionality to the time package, and adding some kind of listing functionality to tzdata seems wrong because it's important that it's only imported at the top level and we wouldn't want the "list time zones" functionality to have the side effect of ignoring system-supplied time zones. I wonder about a new package (time/zones? time/tz?) that exports just a single function, List, that lists the names of all the available time zones. I'll reopen this issue for now, as it's clearly not entirely resolved. |
@rogpeppe, I believe that what I meant back in #20211 (comment) is that once you have LoadLocationFromTZData you can have your own set of time zone data, iterate over it, create locations from it, and so on. For the original scenario above, namely a web server offering a timezone drop-down, it seems like you'd almost certainly want to be using your own specific set of timezone data so that you have control over exactly which version you are using, instead of relying on whatever is built-in to Go or shipped with the operating system (especially on Windows). So I'm not convinced this proposal needs to be reopened, at least not without a new concrete use case to think about. It sounds like maybe you have a new need that might be addressed by List? Can you say more about what it is? |
The argument that it's more robust to be explicit about the set of timezones to include is convincing to me. |
@Merovius It sounds like you are retracting this proposal. Should we close the issue? |
Sure. |
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.
System details
The text was updated successfully, but these errors were encountered: