I think we should make .jsDate use the fields, not the msec value, and that just be it. To select a different timezone, use getInTimezone(). for isDate, you can just use .isDate. It's the same result as a parameter call. You can't do normal comparisation on the .jsDate's anymore (if they can be in different timezones), but for those places we can use calDateTime directly. We should try to minimize the amount of places that use .jsDate anyway, since it's just a mess when trying to deal with timezones.
Can someone build a dependency graph on this bug for the things that such a change would fix? I'm leery of changing how we convert from JS Dates right now, but it probably makes sense to do so before too long if we're going to do it. I generally agree with mvl's assertion that we should move away from .jsDate usage as much as possible, because it really isn't well-suited for the sorts of complex timezone manipulations we want to perform in our calendar code.
Assignee: shaver → nobody
The change would fix .jsDate on a floating time. Currently, .jsDate on a floating datetime pretents the datetime is in UTC, and converts from that, but then also converts to the local timezone. This causes an offset of a few hours, and messes up the unifinder and the weekview, at least.
added 'timezone offset' to summary to make this bug easier to find.
Summary: calIDateTime needs methods to convert to/from jsDate by fields → calIDateTime needs methods to convert to/from jsDate by fields [else wrong timezone offset]
Is this solved by the jsDateToFloatingDateTime(date) function http://lxr.mozilla.org/seamonkey/source/calendar/resources/content/calendarUtils.js#136 and the change to calDateTime http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=calDateTime.cpp&branch=&root=/cvsroot&subdir=mozilla/calendar/base/src&command=DIFF_FRAMESET&rev1=1.46&rev2=1.47 which makes converting from a floating datetime work correctly?
If an app has a date picker (with a jsDate as value) and a timezone picker, or if an app has parsed some jsDates and timezone, how can it simply create a calDateTime with those date fields, in that timezone? It is not obvious from the interface or class, and it should be. My concern is to make a single step technique for converting by fields to make it harder to make mistakes, particularly for people who aren't experienced with the code and don't know how it works internally.
*** Bug 326868 has been marked as a duplicate of this bug. ***
Bug 326868 has details that will be useful in release-noting this bug.
Whiteboard: [cal relnote]
Cleaning up incorrectly assigned bugs; search for dmosecleanup to get rid of this bugmail.
Assignee: dmose → nobody
mvl/gekacheka: Since we can use calDateTime.jsDate(valueFromDatetimepicker) can this be marked FIXED?
No, it can't be closed. Nothing has changed since the bug was filed. jsDate is still totally buggy, especially in combination with the timepicker. (Note the 'by fields' parts in the bug summary. We don't do that)
I think the current approach we are running is ok: feed the (jsDate based) controls floating, and (on the way back) take the raw jsDate's values, omitting the timezone. I've added support for this purpose calUtils's jsDateToDateTime in bug 328442. As far as I understand this bug, IMO we could not safely fix it, because calDatetime and jsDate operate on different timezone definitions. Due to this, a transition from calDatetime into jsDate and back will potentially falsify the original calDatetime.
gekacheka, what's your opinion on my last comment?
I think we can close this bug for now. jsDate might still be broken, but we do the best we can to convert with the correct timezone offset, see calUtils' jsDateToDateTime and calIDateTime's jsDate.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.