Transitive dependencies on TimeZones.jl

[johnbcoughlin]

I was surprised to note that TimeZones was added as a dependency of my project after adding SpecialPolynomials. The dependency graph is through this package, Intervals.jl. The TimeZones library is rather heavy, and brings in multiple dependencies of its own.

It would be preferable if math-only libraries which have no need for date arithmetic didn't have to depend on the entire IANA TZ database. What I propose is hiding the TimeZones dependency behind a Requires.jl @requires block, like so:

function __init__()
    @require TimeZones = "f269a46b-ccf7-5d73-abea-4c690281aa53" include("timezones.jl")
end

where timezones.jl would include all of the TimeZones-specific methods (there are six such methods).

Other options:

• Factoring out TimeZones-specific code into a separate package (TimeIntervals.jl or something).
• Lean into this library providing type-specific logic for dates and times. In that case I think it should be highlighted in the README of the package.
• Get pure math packages to depend on a more minimal version of the Interval type. Unfortunately this would be a breaking change for at least Polynomials.jl.

The easiest is the Requires.jl option. I already have tests passing that way, so let me know if a PR is welcome.

Note that all of the above also goes for the dependency on Dates -- that's not so heavy because it's in the stdlib, but if I were benevolent dictator for life of this package, I would make that dependency optional as well.

Thanks!

[oxinabox]

Not relevent to you in this case as you have already swapped to IntervalSets.jl

We could use Requires.jl to make it an optionally loaded dependency, so that the code isn't loaded.
But we can't remove it from the Project.toml as otherwise we are unable to specify what semver version is compatible with.
Which is unsafe.
The real resolution is JuliaLang/Pkg.jl#1285

But we might we be to do, as you say is just remove those methods entirely.
These ones:

Intervals.jl/src/anchoredinterval.jl

Lines 387 to 393 in f873f70

	##### TIME ZONES #####
	function TimeZones.astimezone(i::AnchoredInterval{P, ZonedDateTime, L, R}, tz::TimeZone) where {P,L,R}
	return AnchoredInterval{P, ZonedDateTime, L, R}(astimezone(anchor(i), tz))
	end
	TimeZones.timezone(i::AnchoredInterval{P, ZonedDateTime}) where P = timezone(anchor(i))

Intervals.jl/src/interval.jl

Lines 483 to 492 in a785b56

	function TimeZones.astimezone(i::Interval{ZonedDateTime, L, R}, tz::TimeZone) where {L,R}
	return Interval{ZonedDateTime, L, R}(astimezone(first(i), tz), astimezone(last(i), tz))
	end
	function TimeZones.timezone(i::Interval{ZonedDateTime})
	if timezone(first(i)) != timezone(last(i))
	throw(ArgumentError("Interval $i contains mixed timezones."))
	end
	return timezone(first(i))
	end

don't really seem idoiomatic julia in the first place.
Since they are kind of like implict broadcasting (removed in julia 1.5) -- not exactly the same.
The timezone of an interval IMO should be found out by asking about time timezone of the endpoints (or the anchor), and set similarly.
I always forget you can do that.
I don't think we do that anywhere in our internal codebase