335882 - Hover on all-day events, balloon popup shows times shifted to UTC

Status: RESOLVED WORKSFORME

(Calendar :: Internal Components, defect)

Description

[Andrew N Dowden]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060428 Mozilla Sunbird/0.3a2

Similar to bug 328911, date are reported as UTC and shifted from local time.

This is only a minor appearance issue, and (with other timezone issues now resolved) does not appear to have any functional effect.


Reproducible: Always

Steps to Reproduce:
1. load (import)  OR create manually
	RRULE:FREQ=YEARLY;INTERVAL=1
	DTSTART;VALUE=DATE:20060205
	DTEND;VALUE=DATE:20060206
2. view (hover-popup)
	Sunday, 5 February 2006 01:00pm - Monday, 6 February 2006 01:00pm
	( treated as UTC against NZ locale (daylight, UTC +13))

Actual Results:  
Sunday, 5 February 2006 01:00pm - Monday, 6 February 2006 01:00pm

Expected Results:  
Sunday, 5 February 2006 12:00am - Monday, 6 February 2006 12:00am

Comment 1

[Joey Minta]

http://lxr.mozilla.org/mozilla/source/calendar/resources/content/mouseoverPreviews.js#359
This seems like we're doing everything correct.  Can you try to track down whether this is a problem with getInTimezone(), calendarDefaultTimezone(), or calIDateTimeFormatter?

Comment 2

[Andrew N Dowden]

Without trying to ignore the error ('sweep it under the carpet')..

Should the popup details show times for all-day events at all?

Comment 3

[Joey Minta]

(In reply to comment #2)
> Without trying to ignore the error ('sweep it under the carpet')..
> 
> Should the popup details show times for all-day events at all?
> 
Hmm, no.  It should probably get the 'All day' string and return that.  This also would explain the bug.  Calling getInTimezone with .isDate==true has no effect.

Comment 4

[Andrew N Dowden]

I think just a date (without time) would work better.  'Less is more.'

Example 1:  (current 0.3a2, then suggested)
  Title: Easter Sunday
  Date: Sunday, 16 April 2006 12:00pm - Monday, 17 April 2006 12:00pm

  Date: Sunday, 16 April 2006

Example 2:  (current 0.3a2, then suggested)
  Title: Christmas Holiday
    (Note: this is 2 day event, in NZ Calendar)
  Date: Monday, 25 December 2006 01:00pm - Wednesday, 27 December 2006 01:00pm

  Date: Monday, 25 December 2006 - Tuesday, 26 December 2006

Comment 5

[Andrew N Dowden]

Further testing on latest nightly (20060508 Sunbird 0.3a2) ..

For all-days events

(a.) For event loaded from iCal file, time shows: 12:00pm - 12:00pm (wrong)

(b.) New event added using Sunbird, shows as 12:00am - 12:00am (correct)

(c.) Edit event (a.) using Sunbird, shows as 12:00am - 12:00am (now correct)
  - this can however, corrupt recurrence logic.

as tested ..

SUMMARY:Queen's Birthday
COMMENT:Observed 1st Monday in June
RRULE:FREQ=YEARLY;BYMONTH=6;BYDAY=1MO;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20050606
DTEND;VALUE=DATE:20050607

Initially showed as (a.), then edit to (c.)  This saved as occurence of each June 6th, NOT first monday.  Deleted all events for that calendar, re-import, and re-edited.  Worked Ok, 2nd time.

Comment 6

[Andrew N Dowden]

This is probably an effect I have seen before.

The all-day event is assigned to the local timezone, and exports as:

RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1MO;BYMONTH=6
DTSTART;VALUE=DATE;TZID=/mozilla.org/20050126_1/Pacific/Auckland:20050606
DTEND;VALUE=DATE;TZID=/mozilla.org/20050126_1/Pacific/Auckland:20050607

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #5)
> Further testing on latest nightly (20060508 Sunbird 0.3a2) ..
> 
> For all-days events
> 
> (a.) For event loaded from iCal file, time shows: 12:00pm - 12:00pm (wrong)

This is a DUP of 254893.

> (c.) Edit event (a.) using Sunbird, shows as 12:00am - 12:00am (now correct)
>   - this can however, corrupt recurrence logic.
> 

Editing should not change the timezone modality of times attached to an event.  I thought there was already a bug filed about this, but I can't find it now.  If you wanted to find or file a bug on that, that'd be great.

Comment 8

[Andrew N Dowden]

per comment 7
> Editing should not change the timezone modality of times attached to an event. 
> I thought there was already a bug filed about this, but I can't find it now. 
> If you wanted to find or file a bug on that, that'd be great.

This probably most relates to bug 333717 (Timezone infomation lost ..)

In bug 333717 comment 6, I noted loss due to 'edit before save' ..

But I can't ALWAYS reproduce it.  It does NOT always change the timezone, and 20+ attempts had 4 dates always change to local, and the others did NOT.  This was with latest Sunbird nightly, just loaded calendars, all other details identical (as far as I can tell)..

I will need to raise a seperate bug, BUT still trying to identify ANY causal factors to variance I am seeing.

Comment 9

[Andrew N Dowden]

This is also possibly a varaint of bug 337191, but relating to confusion between NZ local (UTC-12) and UTC.

The use of both timezones being a remnant of one (or more) of the tz issues currently outstanding.

Comment 10

[Joey Minta]

Given comment #7, it's not clear to me what remains to be done in this bug.  Can someone clarify?

Comment 11

[Andrew N Dowden]

As I am reviewing and testing the nightly app (and NOT the code), I have yet to see a version that addresses comment 4.  Nor have I yet seen a nightly that has the issues from comment 7 (,8 & 9) addressed, although they are seperate tz bugs.

Suggestions? ..

Comment 12

[Joey Minta]

Bug 331145 should help substantially with comment #4.  In theory it'll get the 'All day' terminology to show up.

Comment 13

[Reed Loden [:reed]]

The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!

Comment 14

[Stefan Sitter [:ssitter]]

Andrew,
Bug 331145 was fixed. 
Does the issue still exist with current nightly builds of Sunbird?

Comment 15

[Andrew N Dowden]

Tested on nightly (20060828 Calendar/0.3a2+)

per Comment 4
 - now works correctly, as suggested.

per Comment 7
 - no longer relevant, as changes do not create this problem.

So, works for me.

Comment 16

[Matthew (lilmatt) Willis]

As there's no patch associated with the fix, marking WFM