325981 - Move minimonth/datetimepicker from jsDate to calDateTime

Status: RESOLVED INVALID

(Calendar :: Internal Components, defect)

Description

[Joey Minta]

Currently, the minimonth and datetimepicker use javascript dates throughout their internal structure.  The rest of the calendar code is written using calIDateTime objects.  This creates several problems, especially with timezone conversions (see bug 304084, bug 296659, bug 321560).  I'm filing this bug to get some discussion on record about whether or not the best way to solve this is to move the minimonth/datetimepickers to calDateTime.

Advantages:
-No more tz-issues (fixes all of the above mentioned bugs)
-No need for conversion functions

Disadvantages:
-The minimonth/datetimepicker can no longer be moved to toolkit.

calDateTime depends on libical which I highly doubt toolkit wants to work with.  If we make this change, it will be near impossible to use these widgets as the common date/timepicker for toolkit.  This discussion has come up before, and I'm CC'ing everyone who I can remember participated in it.

We really need to decide whether this minimonth->toolkit thing is possible/going to happen.  A lot of this discussion took place previously in bug 317311.  brettw in bug 317311 comment #15 pushed the decision toolkit-date/time widgets to another bug, which I haven't seen filed, so hopefully the decision can be made here (or at least some guidance can be given).

Comment 1

[Mike Connor [:mconnor]]

At this point, we have two very different datepickers floating around.  If they're going to be wholly incompatible, we'll just have to suffer a bit of bloat from either reimplementing the one for places or just carrying a generic one.

Comment 2

[Joey Minta]

Attachment: move to calDateTime

Moves to calDateTime.  Probably will hurt perf a bit until we can get around to cleaning up this code but should fix the 2 lightning 0.1 blockers and simplify our code a good deal.

Comment 3

[Joey Minta]

After discussion in IRC, we've decided that we're not going to introduce this dependency.  Eventually, we'll probably change the datetimepickers to simply return fields, rather than jsDates or calDateTimes, and wrappers can then construct the desired object.  Resolving INVALID, hoping this actually does move to toolkit in the near future.