Julia: Dates module is still a big source of ambiguities

[timholy]

Methods in Dates have a habit of causing ambiguities for packages that define new AbstractArray types, e.g., https://github.com/andyferris/StaticArrays.jl/issues/18 where nearly half of the ambiguities are due to Dates-related methods. The problem, in a nutshell, is that Dates specializes several AbstractArray methods on the element type whereas packages tend to specialize on the container type.

Getting rid of such ambiguity warnings, back in the days of 0.4-dev, was the final trigger for introducing promote_op (#12292 and #12370); now that we've gotten rid of it, it would be lovely to see whether we can reduce the ambiguity-causing footprint of Dates even further.

Now that ambiguities are silent until called this is not as crucial as it once was, but ideally we'd like to move to a world where packages can include detect_ambiguities as part of their tests.

[JeffreySarnoff]

+1 (this is the sort of issue that gets more cumbersome with time and increased kinds of use)

[StefanKarpinski]

Dates should largely move out of the standard library aside from a few core type definitions so that functions like now() can return a value of the right type.

[JeffBezanson]

Is this related to #23167? Are the vectorized methods exactly the ambiguous ones?

[timholy]

Hard to check the OP at the moment since StaticArrays doesn't build on current versions of 0.7.

[StefanKarpinski]

No longer a milestone blocker since the plan is to move Dates out of Base: https://github.com/JuliaLang/julia/issues/23302.

[quinnj]

Duplicate of https://github.com/JuliaLang/julia/issues/28672 (yes, I know, this issue came first, but oh well).