excise most of Dates from Base

[StefanKarpinski]

The Dates submodule is quite large and has a lot of functionality which is still very much a work in progress. To that end, it should be split into just the bare minimum functionality that needs to be in Base, which IMO is:

• type definitions
• printing in ISO standard format
• some basic arithmetic?

If you want to do anything more complex with dates or times, you'll have to load a (standard) package. The only reason to have dates and times in Base at all is so that functions like now() can produce datetime values.

Would close (move out of this repo) the following issues:

https://github.com/JuliaLang/julia/issues?q=is%3Aopen+is%3Aissue+label%3Adates

Most of these should technically be a 1.0 blocker. The only viable alternative I can see is to keep Dates in Base but declare it to be unstable despite the 1.0 release and continue to evolve it.

[aviks]

I'm not really convinced of this plan. Dates seem pretty basic. I would suggest that Dates are the most used type in base after Int, Float64 and String.

Many of the issues are for constructor or constructor like methods. Will we have the types in base, but not the constructors? That seems like a deep dependency that will negate any benefit of separation.

I'm not sure what basic arithmetic is, as opposed to non basic. We basically do addition and subtraction. Do mean removing other time instances? Some of the shorter time instances will be required to get arithmetic with Dates, but maybe you could drop the longer spans. So base will have seconds and hours but not week and month?

So I'm not clear how this will work.

[quinnj]

I disagree with the statement "a lot of functionality which is still very much a work in progress". Dates have been in for what, 3 years now? Most of those issues are easy closes (I can plan on triaging/closing over the next week) and not major design issues.

I do agree that Dates would make excellent StdLib material. It's very self contained and doesn't rely on any binaries or anything. I agree w/ @aviks though that trying to break it up at all would probably just make things messier.

[tkelman]

I think it would make more sense to move the whole thing. It has been in Base for a while and remains mostly decoupled. Base functions like now could be given return type arguments, the Dates standard package would define now(DateTime) or similar.

[StefanKarpinski]

A lot of the linked dates-related issues have a feel of not just being bug fixes or minor feature additions. Several of them have a feeling of needing some significant API redesign. For example, having a lot of method ambiguities is usually a sign of a fundamental problem. Concerns about the type hierarchy. Constructor versus parse methods. Conversion issues. And of course, there's JuliaLang/Juleps#36, which would require changing the representation.

I'm not saying that there's anything wrong with Dates or that it's not important – in fact I want it out of Base (or declared unstable) because it's important and I don't want it becoming ossified before it's really ready. Dates has been a great success, but I just have a gut feeling that we will want to change things that the 1.0 stability promise will prevent us from changing. And that would really be a shame.

[c42f]

Dates has been a great success, but I just have a gut feeling that we will want to change things that the 1.0 stability promise will prevent us from changing

I agree with this. In particular, I'm concerned that any attempt to change the representation might be quite breaking. I do think something like the day-segmented time of JuliaLang/Juleps#36 is the right way to go, but that seems to have stalled for now.

My feeling is that DateTime is a great tool for calendrical calculations, but leaves some big questions unanswered for scientific timekeeping where high precision and the ability to represent leap seconds can be important. Perhaps, arguably, people shouldn't be using a DateTime for such scientific purposes, but I feel like the story could be more coherent here. (Even if experimental time is measured from an epoch, it's rather handy to be able to talk about the epoch itself using a DateTime if you have a need to compare or index various experiments, and when third party equipment insists on talking to you in high precision UTC.)

[JeffreySarnoff]

my view on this

redo it with lessons learned and issue avoidance and interworkability of multiple representations
then provide a package that allows old datetime stuff to be used via passthrough/massaging stuff
then those who need old datetime stuff are ok
and the world of Julia can start being subnanosec+gigayear

we are efforting hope that-a-way here

there will a few thing that Base should have for transparency -- idk exactly what they are as yet

if we have a basic tic-toc clock that serves as a calendar_date_and_time_of_day type that is equi-available as a 64bit wrapper and as a 128bit wrapper (y'all know better than I .. struct baseclock{param_for_size or resolution} .. or a generated? struct or what occurs to you) then the rest can be had theWithout that, things will stay stay messy because ther are equi-important conflicting needs (physics experiments, legal requirements, &etc).

[malmaud]

A relevant case-study is Arrow, which is a better version of dates for Python that is free to evolve independently of Python's slow release cycle.

[nalimilan]

Could we imagine moving now to the Dates package? People can still use Libc.TimeVal() if they really want the raw number of seconds since the epoch.

[StefanKarpinski]

Could we imagine moving now to the Dates package?

That's not a bad idea actually – there's no reason that now needs to be in Base since we have time() which gives the current time as a floating-point value.

[quinnj]

Yeah, that seems fine; again, I think it should just all go together into it's own StdLib package.

Which, BTW, anyone working on that? Isn't that a pretty desirable 1.0 feature? I know there's been a few PRs here & there, but we probably need a more concentrated effort there to really get something that works.

[StefanKarpinski]

Which, BTW, anyone working on that?

I'm headed to Boston next week and the plan is to do a bunch of work on code loading, part of which is standard library packages. So that will be started soon.

[StefanKarpinski]

Plan: move Dates to a standard package, including now() and any other methods that produce dates or datetime objects.

[JeffreySarnoff]

"and any other .. dates or datetime objects" --> "and any other .. [reworked] dates or datetime objects"

[omus]

I'd be happy to have Dates move out of Base. One big change I'd like to do is try to move away from assuming that Day(1) == Hour(24) (not always true with time zones). I'm not sure where StdLib packages will reside but I think the JuliaTime organization is the logical home.

[JeffreySarnoff]

+1

[StefanKarpinski]

Standard packages may actually be subtrees of the main Julia repo.

[KristofferC]

What's the decision here? Move to stdlib?

[quinnj]

I’d say definitely

[KristofferC]

Okay, so not into its own external package then (outside the Julia repo?)

[JeffBezanson]

Yes, let's move it to stdlib. That will be the default choice for modules that used to be in Base. From there it's much easier to move things to external repos later if we want (since Base.X gets deprecated).

[StefanKarpinski]

Especially since using Foo will either prompt you to install Foo or in some cases (tbd what circumstances) just automatically install it. So it will be a nearly invisible change when we move things out of the stdlib, hopefully.