Date and datetime

[randomstuff]

Rename Date into DateTime and add CalendarDate (for date).

Same for DateRange.

For compatiblity Date is an alias for DateTime. The idea is to rename CalendarDate into Date later on.

see #346 and #168

[philippjfr]

This looks great to me. @jbednar @jlstevens Any objections?

[randomstuff]

(Merged the first two commits)

[jbednar]

This all looks good to me. I can't see any problems with backwards compatibility, and this is a much better approach going forwards. I'm happy for it to be merged once the above minor docs issues are either addressed or resolved as not relevant. Thanks so much for submitting this, and I'm sorry for having taken so long to review it (blame SciPy2019 and all of its amazingness!).

[randomstuff]

If this change is merged I'm not sure it makes sense to allow Datetime and DateTimeRange to hold date values instead of datetime ones. I find it's pretty strange:

import datetime

import param

class Foo(param.Parameterized):
    p = param.DateTime()

foo = Foo()
foo.p = datetime.date.today()
print(repr(foo.p)) # => datetime.date(2019, 7, 25)

Changing this would be a breaking change however.

[randomstuff]

Fixed the documentation of the changes which has some confusing regarding datetime vs date, etc.

[randomstuff]

Another solution would be to keep Date dand DateRange for now (with the idea or replacing them later on with CalendarDate and CalendarDateTime) which would support both for now and add new DateTime and DateTimeRange which would only accept datetime

[randomstuff]

Updated to this alternative proposition:

• keep Date unmodified;
• CalendarDate for date-only.

I'd be tempted to add (in other PRs):

• NaiveDateTime for naive date times (no timezone information);
• DateTime (?) for non-naive datetime;
• Time for (naive) time.

[philippjfr]

Thanks @randomstuff! Sorry for the long review cycle. This is hugely appreciated.

[randomstuff]

I was looking of the different panel widgets and how they would behave if using CalendarDate instead of Date this change and I discovered that datetime is actually a subclass of date. 😲

As a consequence, CalendarDate can currenly hold datetime values which is not what I intended. 😄 The only difference between Date and CalendarDate is that the latter cannot hold a np.datetime64 value (because np.datetime64 is not a subclass of date). This is somewhat nice because np.datetime64 does not behave as a date at all (no .month, etc.).

Conclusion:

• As datetime is a subclass of date, it is kind-of expected that the Date/CalendarDate parameters would accept datetime values so the Date parameter type is actually OK in this regard.

• I wonder if it would not be useful to convert datetime to date on assignment (either for Date/CalendarDate).

• I'm not sure CalendarDate is actually any useful in its current state and I'd vote for reverting it for now (at least before release if no clear plan as been found).

• Allowing Date parameters to hold np.datetime64 could be problematic because np.datetime64 does not behave as date at all. It might be more useful to convert np.datetime64 to datetime/date automatically when assigning (?).