Skip to content
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

Changing tzdata version at runtime #420

Open
tpgillam opened this issue Dec 2, 2022 · 1 comment
Open

Changing tzdata version at runtime #420

tpgillam opened this issue Dec 2, 2022 · 1 comment

Comments

@tpgillam
Copy link
Contributor

tpgillam commented Dec 2, 2022

I'm wondering what the best way is to change the version of tzdata used at runtime.

For context: I'd like to do this in tests for a small utility to find timezones from coordinates., specifically see this PR

Currently what I'm doing uses the (undocumented) JULIA_TZ_VERSION environment variable, and roughly amounts to running:

ENV["JULIA_TZ_VERSION"] = "<some old version>"
TimeZones.build()
# ... some tests with old tzdata...

delete!(ENV, "JULIA_TZ_VERSION")
TimeZones.build()
# ... some tests with current tzdata...

It seems as though I could maybe skip the environment variable by specifying a version directly to build, but then I think that would make TimeZones._COMPILED_DIR inconsistent with TimeZones.TZData.tzdata_version(). This seems bad to me, even if that would be "simpler" from a user perspective (i.e. not needing to modify the environment variable).

If it is appropriate, I'll happily make a documentation PR including whatever is suggested.

Thanks!

@omus
Copy link
Member

omus commented Dec 13, 2022

You can just use TimeZones.build and pass in a tzdata version:

julia> TimeZones.build("2016a")
[ Info: Installing 2016a tzdata region data
[ Info: Converting tz source files into TimeZone data
[ Info: Successfully built TimeZones

julia> TimeZones.build()
[ Info: Installing 2022f tzdata region data
[ Info: Converting tz source files into TimeZone data
[ Info: Successfully built TimeZones

However, you are correct that then TimeZones.TZData.tzdata_version() becomes inconsistent with the currently built version. We can definitely improve this situation and make things better here. I'll mention that to date this functionality hasn't been used (AFAIK) outside of TimeZones.jl so this is a good use case for making this work nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants