JuliaLang
split internal dates methods into separate functions
I still like the changes.
Need to adjust rata2datetime and datetime2rata to use _yearmonthday, too.
Yeah, it's confusing to me too. I'm trying to figure out how to rerun the build in case it's a buildkite issue. I've never seen a failure like this.
Thanks for the bump. Next steps are to fix test failures in CI and then run pkgeval. Here's a real test failure from CI:
Error During Test at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-grannysmith-C07ZQ07RJYVY.0/build/default-grannysmith-C07ZQ07RJYVY-0/julialang/julia-master/julia-8d470900e4/share/julia/stdlib/v1.12/Dates/test/accessors.jl:59
--
| Test threw exception
| Expression: (y, m, d) == Dates.yearmonthday(days)
| MethodError: no method matching yearmonthday(::Int64)
| The function `yearmonthday` exists, but no method is defined for this combination of argument types.
Hmmm, some of these methods are tested directly in https://github.com/JuliaLang/julia/blob/c6c449ccdb75fbd72700704ae669e1f98e512206/stdlib/Dates/test/accessors.jl#L8-L46
Any idea whether it was intended as a public api (yearmonthday(x) and others taking any number) or not?
I don't see that usage documented, so no: not public. Those tests should be switched to testing _yearmonthday and friends. Nanosoldier can tell us if packages depend on those undocumented internals.
@nanosoldier runtests()
The package evaluation job you requested has completed - possible new issues were detected. The full report is available.
The failures in Kedzi, NanoDates, and Dates look real. If this were breaking something that was ever public, I would be concerned. As is, we should investigate Kexzi and NanoDates's failures and it would be polite to make PRs that fix them but I don't view those nanosoldier failures as blocking.