If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

All Day Event on Wrong Day / changes Time Zone

RESOLVED FIXED

Status

Calendar
Provider: WCAP
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: uriahq, Assigned: dbo)

Tracking

Lightning 0.9
x86
Linux

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080410 SUSE/2.0.0.14-2.3 Firefox/2.0.0.14
Build Identifier: 2008091718

Seen under Windows and Linux version of Lightning 0.9, but not 0.8 connecting to Sun Communication Suite 5.

If you create an event with a start and stop time it stores it in the calendar at the time it should.  If you create an All Day Event it stores it a day early.  You will notice that when you click on the All Day Event check box your Timezone changes from your set Timezone (ie America/New York) to Local Time.   If you Change your time zone for the event to Europe/London before clicking on All Day Event, the event gets saved to the right day.

OS and Thunderbird is set to the same Time Zone.
Does not seam to reproduce if stored to Non-Network Calendar.


Reproducible: Always

Steps to Reproduce:
1. Create New Event
2. Click on All Day Event
3. Save
4. Verify event is now 1 day early.



Tested on:
Linux Thunderbird 2.0.0.9 Lightening 0.9
Windows Thunderbird 2.0.0.19 Lightening 0.9

Behavior was correct when Lightening 0.8 was used on both platforms.
(Reporter)

Updated

9 years ago
Version: unspecified → Lightning 0.9

Comment 1

9 years ago
Could not reproduce behavior against a CalDAV (Yahoo/Zimbra) server.
(MSWindows Thunderbird 2.0.0.19, Lightning 0.9)
Therefore I suspect it is either a problem with the Lightning WCAP provider or the Sun Communication Suite 5.

The Sun Communication Suite 5 release notes do mention one problem with all-day events:

"The following are additional issues related to the calendar portion of Connector for Microsoft Outlook that do not have IDs:
...
      All Day events may become a non-All Day events (one event scheduled from 12:00am until 12:00pm) if the desktop time zone is different from the Calendar Server calendar time zone."
http://docs.sun.com/app/docs/doc/819-4432/acejc?l=en&a=view&q=all+day

Possibly related:  bug 468842, bug 437420
Component: General → Provider: WCAP
QA Contact: general → wcap-provider
(Reporter)

Comment 2

9 years ago
That Sun bug is only for the Outlook Connector Pluggin installed into Outlook, not the Sun Calendar server.

I identically created two All Day events for Feb 14th, one using Lightening 0.8 the other with Lightening 0.9, and then went to the web UI of the server and exported them as VCAL.  Please see below. 

BEGIN:VEVENT
UID:00000000000000000000000000000000733b904907110000cb0200008e030000
DTSTAMP:20090209T142155Z
SUMMARY:Lightening 0.8 Event
DTSTART;VALUE=DATE:20090214
DTEND;VALUE=DATE:20090215
CREATED:20090209T141931Z
LAST-MODIFIED:20090209T141931Z
PRIORITY:0
SEQUENCE:0
CLASS:PUBLIC
ORGANIZER;CN="Uriah Queen"
 ;X-S1CS-EMAIL=queenux@xxxxxx.xxx
 :queenux@xxxxxx.xxx
STATUS:CONFIRMED
TRANSP:TRANSPARENT
X-NSCP-DTSTART-TZID:UTC
X-NSCP-DTEND-TZID:UTC
X-NSCP-ORIGINAL-DTSTART:20090214T050000Z
X-NSCP-LANGUAGE:en
X-NSCP-DTSTART-TZID:America/New_York
X-NSCP-TOMBSTONE:0
X-NSCP-ONGOING:0
X-NSCP-ORGANIZER-EMAIL:queenux@xxxxxx.xxx
X-NSCP-GSE-COMPONENT-STATE;X-NSCP-GSE-COMMENT="PUBLISH-COMPLETED":65538
END:VEVENT

BEGIN:VEVENT
UID:00000000000000000000000000000000aa3b90490d3000009f02000029030000
DTSTAMP:20090209T142155Z
SUMMARY:Lightening 0.9 Event
DTSTART;VALUE=DATE:20090213
DTEND;VALUE=DATE:20090214
CREATED:20090209T142027Z
LAST-MODIFIED:20090209T142027Z
PRIORITY:0
SEQUENCE:0
CLASS:PUBLIC
ORGANIZER;CN="Uriah Queen"
 ;X-S1CS-EMAIL=queenux@xxxxxx.xxx
 :queenux@xxxxxx.xxx
STATUS:CONFIRMED
TRANSP:TRANSPARENT
X-NSCP-ORIGINAL-DTSTART:20090214T000000Z
X-NSCP-LANGUAGE:en
X-NSCP-TOMBSTONE:0
X-NSCP-ONGOING:0
X-NSCP-ORGANIZER-EMAIL:queenux@xxxxxx.xxx
X-NSCP-GSE-COMPONENT-STATE;X-NSCP-GSE-COMMENT="PUBLISH-COMPLETED":65538
END:VEVENT

I notice that X-NSCP-ORIGINAL-DTSTART != DTSTART for the 0.9 created one but they do for the 0.8 created one.  Also it appears that X-NSCP-DTSTART-TZID gets removed from the newer plugin.
Does this also happen with 1.0pre?
(Reporter)

Comment 4

9 years ago
I could not get the nightly build of Lightening to install with Thunderbird 2.x or 3.x.  Instead used Sunbird nightly and it too creates the event a day ahead of schedule.  I pasted the version number in the Description.

BEGIN:VEVENT
UID:0000000000000000000000000000000023809049d05d0000d30100008b030000
DTSTAMP:20090209T191602Z
SUMMARY:Sunbird 1.0pre Event
DTSTART;VALUE=DATE:20090213
DTEND;VALUE=DATE:20090214
CREATED:20090209T191235Z
LAST-MODIFIED:20090209T191235Z
PRIORITY:0
SEQUENCE:0
DESCRIPTION:Mozilla/5.0 (Windows\; U\; Windows NT 5.1\; en-US\; rv:1.9.1b3
 pre) Gecko/20090209 Calendar/1.0pre
CLASS:PUBLIC
ORGANIZER;CN="Uriah Queen"
 ;X-S1CS-EMAIL=queenux@xxxxxx.xxx
 :queenux@xxxxxx.xxx
STATUS:CONFIRMED
TRANSP:TRANSPARENT
X-NSCP-ORIGINAL-DTSTART:20090214T000000Z
X-NSCP-LANGUAGE:en
X-NSCP-TOMBSTONE:0
X-NSCP-ONGOING:0
X-NSCP-ORGANIZER-EMAIL:queenux@xxxxxx.xxx
X-NSCP-GSE-COMPONENT-STATE;X-NSCP-GSE-COMMENT="PUBLISH-COMPLETED":65538
END:VEVENT
(Assignee)

Comment 5

9 years ago
I think you run into a shortcoming of the server. The server doesn't support floating dates at all, thus your all-day events get saved in the server-configured timezone. If your local (lightning, view) timezone setting doesn't match, you'll likely see a disparity. Please try to align your server timezone-setting (calendar express: Calendar->Edit->Timezone) with lightning's, e.g. both set to Europe/Paris or the like.
(Reporter)

Comment 6

9 years ago
Lightening, Desktop OS, Server OS, and User config on server are all on the same Time Zone.  

When the values of DTSTART and DTEND are set, are you suggesting that the server is subtracting a day because there is no X-NSCP-DTSTART-TZID?  I've tried creating similar events using the web interface and through Notify Link and they create fine.  They behave like Lightening 0.8 does.


BEGIN:VEVENT
UID:0000000000000000000000000000000029899049d77c0000de0200008e030000
DTSTAMP:20090210T194357Z
SUMMARY:NL Event
DTSTART;VALUE=DATE:20090214
DTEND;VALUE=DATE:20090215
CREATED:20090209T195105Z
LAST-MODIFIED:20090209T195105Z
PRIORITY:0
SEQUENCE:0
CLASS:PUBLIC
ORGANIZER;CN="Uriah Queen"
 ;X-NSCP-ORGANIZER-UID=queenux@xxxxxx.xxx
 ;X-S1CS-EMAIL=queenux@xxxxxx.xxx
 :queenux@xxxxxx.xxx
STATUS:CONFIRMED
TRANSP:TRANSPARENT
X-NSCP-ORIGINAL-DTSTART:20090214T050000Z
X-NSCP-LANGUAGE:en
X-NSCP-DTSTART-TZID:America/New_York
X-NSCP-TOMBSTONE:0
X-NSCP-ONGOING:0
X-NSCP-ORGANIZER-EMAIL:queenux@xxxxxx.xxx
X-NSCP-GSE-COMPONENT-STATE;X-NSCP-GSE-COMMENT="REQUEST-COMPLETED":131074
END:VEVENT


BEGIN:VEVENT
UID:00000000000000000000000000000000cbd8914931440000da0100008b030000
DTSTAMP:20090210T194357Z
SUMMARY:Web UI Event
DTSTART;VALUE=DATE:20090214
DTEND;VALUE=DATE:20090215
CREATED:20090210T194307Z
LAST-MODIFIED:20090210T194307Z
PRIORITY:0
SEQUENCE:0
CLASS:PUBLIC
ORGANIZER;CN="queenux@xxxxxx.xxx (Uriah Queen)"
 ;X-S1CS-EMAIL=queenux@xxxxxx.xxx
 :queenux@xxxxxx.xxx
STATUS:CONFIRMED
TRANSP:TRANSPARENT
CATEGORIES:Business
X-NSCP-ORIGINAL-DTSTART:20090214T050000Z
X-NSCP-LANGUAGE:en
X-NSCP-DTSTART-TZID:America/New_York
X-NSCP-TOMBSTONE:0
X-NSCP-ONGOING:0
X-NSCP-ORGANIZER-EMAIL:queenux@xxxxxx.xxx
X-NSCP-GSE-COMPONENT-STATE;X-NSCP-GSE-COMMENT="REQUEST-COMPLETED":131074
END:VEVENT


If I look in the error console I notice the following.  Is there a way of getting Lightening or Sunbird to log its communications so that one can see what it is passing to the server?

### WCAP log entry: 2009/02/10 15:09:24 America/New_York isDate=0
[context-id: 094c9315-8f79-4931-bf71-61daae1c0b5b, uri: https://xxxxxx.xxx/, userId=queenux, default calendar]
error: defaultTimezone: cannot get X-NSCP-CALPROPS-TZID!
stack:
1: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapUtils.js:167] logError
2: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapCalendar.js:326] calWcapCalendar_defaultTimezoneGetter
3: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapCalendar.js:341] calWcapCalendar_getAlignedTzid
4: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapCalendarItems.js:582] calWcapCalendar_storeItem
5: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapCalendarItems.js:694] calWcapCalendar_adoptItem
6: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapCalendarItems.js:703] calWcapCalendar_addItem
7: [null:0] null
8: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calTransactionManager.js:194] cT_doTransaction
9: [null:0] null
10: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calTransactionManager.js:69] cTM_createAndCommitTxn
(Assignee)

Comment 7

9 years ago
Yes, your log indicates there's no timezone configured for your calendar (X-NSCP-CALPROPS-TZID); please check your Calendar->Edit->Timezone setting in calendar express Web-UI.
Don't be confused by lightning's event dialog enforcing all-day events to be floating: that's correct and suggested, even though the wcap server cannot handle it (items will always get a timezone specifier after saving).

IIRC I've been changes to all-day items for 1.0pre, thus I'd appreciate you get a recent nightly running...
(Reporter)

Comment 8

9 years ago
I reiterate, Time Zone is set in Calendar Express / Communications Express UI.  I tried nightly build "Mozilla/5.0 (Windows\; U\; Windows NT 5.1\; en-US\; rv:1.9.1b3 pre) Gecko/20090209 Calendar/1.0pre" in Comment #4. It has same behavior as 0.9 including message on the error console.
(Reporter)

Comment 9

9 years ago
Found the DEBUG LOG in SunBird 1.0pre.  Am I understanding what is happening in the logs below?

The client connects and tries to set up a new event with Timezone: Floating and fails.  It then tries to get the default Timezone from X-NSCP-CALPROPS-TZID and fails.  Falls back to Timezone: UTC, instead of Timezone: Client. Submits event with proper dtstart= & dtend=.  It appears as though its the server that subtracting a day from dtstart & dtend.


### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[context-id: ae6e31df-e3b3-4fd9-9e74-7a359413d3a9, uri: https://xxxxxx.xxx/, userId=queenux, default calendar]
adoptItem() call: New Event

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
not a supported timezone: floating

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[context-id: ae6e31df-e3b3-4fd9-9e74-7a359413d3a9, uri: https://xxxxxx.xxx/, userId=queenux, default calendar]
warning: defaultTimezone: cannot get X-NSCP-CALPROPS-TZID!

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[context-id: ae6e31df-e3b3-4fd9-9e74-7a359413d3a9, uri: https://xxxxxx.xxx/, userId=queenux, default calendar]
floating not supported, falling back to default: UTC

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[context-id: ae6e31df-e3b3-4fd9-9e74-7a359413d3a9, uri: https://xxxxxx.xxx/, userId=queenux]
login queue lock: false, length: 0

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[context-id: ae6e31df-e3b3-4fd9-9e74-7a359413d3a9, uri: https://xxxxxx.xxx/, userId=queenux]
login queue lock: false, length: 0

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[calWcapRequest id=b8540e3e-57a3-4a04-adf0-53e078777e9d-33, parent-id=<none> ([context-id: ae6e31df-e3b3-4fd9-9e74-7a359413d3a9, uri: https://xxxxxx.xxx/, userId=queenux, default calendar]
adoptItem() call: New Event), isPending=true, status=NS_OK]
attachSubRequest()

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[calWcapNetworkRequest id=b8540e3e-57a3-4a04-adf0-53e078777e9d-34, parent-id=b8540e3e-57a3-4a04-adf0-53e078777e9d-33 (https://xxxxxx.xxx/storeevents.wcap?appid=mozilla-calendar&id=1YeD7XKYEXM&dtstart=20090214&dtend=20090215&isAllDay=1&rrules=&rdates=&exrules=&exdates=&orgCalid=queenux%40xxxxxx.xxx&summary=New%20Event&categories=&desc=&location=&icsUrl=&priority=0&icsClass=PUBLIC&status=0&transparent=1&attachments=&alarmStart=&alarmPopup=&alarmEmails=&tzid=UTC&storetype=1&mod=4&method=1&replace=1&fetch=1&relativealarm=1&compressed=1&recurring=1&emailorcalid=1&fmt-out=text%2Fcalendar&calid=queenux%40xxxxxx.xxx), isPending=true, status=NS_OK]
opening channel.

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[calWcapNetworkRequest id=b8540e3e-57a3-4a04-adf0-53e078777e9d-34, parent-id=b8540e3e-57a3-4a04-adf0-53e078777e9d-33 (https://xxxxxx.xxx/storeevents.wcap?appid=mozilla-calendar&id=1YeD7XKYEXM&dtstart=20090214&dtend=20090215&isAllDay=1&rrules=&rdates=&exrules=&exdates=&orgCalid=queenux%40umdnj.edu&summary=New%20Event&categories=&desc=&location=&icsUrl=&priority=0&icsClass=PUBLIC&status=0&transparent=1&attachments=&alarmStart=&alarmPopup=&alarmEmails=&tzid=UTC&storetype=1&mod=4&method=1&replace=1&fetch=1&relativealarm=1&compressed=1&recurring=1&emailorcalid=1&fmt-out=text%2Fcalendar&calid=queenux%40umdnj.edu), isPending=true, status=NS_OK]
status: NS_OK
(Assignee)

Comment 10

9 years ago
The line:

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[context-id: ae6e31df-e3b3-4fd9-9e74-7a359413d3a9, uri: https://xxxxxx.xxx/,
userId=queenux, default calendar]
warning: defaultTimezone: cannot get X-NSCP-CALPROPS-TZID!

is interesting. Your calendar properties don't contain a configured timezone. Strange. The calendar properties are retrieved almost at startup, see the top of the log. Could you please show them?
Moreover, which version of the server are you running (+patch level)?
(Reporter)

Comment 11

9 years ago
   PKGINST:  SUNWics5
      NAME:  Calendar Server (Core)
  CATEGORY:  application
      ARCH:  i386
   VERSION:  6.0,REV=2003.11.14.17.38.10

Patch: 121658-29 & 122738-15
(Reporter)

Comment 12

9 years ago
Interesting, the calendar attributes in Directory are:

icsTimezone: America/New_York
icsExtendedUserPrefs: ceAllCalendarTZIDs=0
icsExtendedUserPrefs: sunCalInitialized=true
icsExtendedUserPrefs: ceSingleCalendarTZID=0

But in the Calendar store they are:

queenux@xxxxxx.xxx: owner=queenux@xxxxxx.xxx status=enabled
 name=Uriah Queen
 description=
 other owners=
 double book=yes
 email=
 time zone=
 categories=
 character set=
 language code=en
 created=Aug 23, 2007 15:18:05 GMT
 last modified=Jul 24, 2008 19:33:05 GMT
 events last modified=Feb 11, 2009 14:57:46 GMT
 todos last modified=Feb 11, 2009 00:26:11 GMT
 deletelog last modified=Feb 10, 2009 19:30:15 GMT
(Assignee)

Comment 13

9 years ago
(In reply to comment #11)
>    PKGINST:  SUNWics5
>       NAME:  Calendar Server (Core)
>   CATEGORY:  application
>       ARCH:  i386
>    VERSION:  6.0,REV=2003.11.14.17.38.10
> 
> Patch: 121658-29 & 122738-15

Man, this is quite old. Development has been done against a 6.2 + patches 32 and upwards... Any chance to update your service?
(Reporter)

Comment 14

9 years ago
I believe that all distributions was brought up to 6.3 with one of the patches in the late teens, early 20s.  (Can't pinpoint it in the change log) Patch 32 is scheduled for our test environment, although change log does not mention anything that would assist with this issue.
uriahq (reporter), any update on this issue?
(Reporter)

Comment 16

9 years ago
Working with the vendor on the issue and I think they are starting to look at the following issue, which appears to be closely tied to the wrong day/all day issue.

"The DTSTART-TZID token being missing is new to Lightening/Sunbird 0.9 and all pre-1.0 releases.  All, all-day events are now stored as a 'floating' time that has no time zone.  After some digging around found that if you create a new event and set the event's time zone to Local Time you can set any event to 'floating' or 'no timezone'.  Any regular event I create this way shows up 4 hours early.  IE a Noon event will save as 8am."

Although I don't know if its a bug in Thunderbird but the fact that Local Time and UTC are not available as Time Zones for when you create a Sun Java event, but is the only option for all day events.  

I can fool Lightening into creating a Localtime or UTC event by changing calendar store to Personal (local store), change time zone, then change back to Sun Java. The entry now has a time zone that the client would not normally allow the user to choose.

Comment 17

8 years ago
-> NEW, I have the same system and this happens to me.

If you set the time zone of the calendar, that seems to make the problem go away.

It sounds like the very last problem (among the many mentioned here) is that when the data comes back to Sunbird from the client, the empty timezone causes the event to go to GMT+0, which, for most users in the US, would send it into "yesterday".
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 18

8 years ago
(In reply to comment #17)
What do you expect to be fixed client-side then? Users should make sure the server accounts are properly configured.

The WCAP server sends data as UTC with separate X-props specifying the timezones. If those aren't available, the client cannot guess them.

I tend to set this to WORKSFORME, since it's a server and/or server config/admin problem.
(Reporter)

Comment 19

8 years ago
You CAN NO LONGER set a Timezone for ALL DAY EVENTS in Lightening 0.9 and newer.  The client (Lightening) will send over the event as UTC which the server barf and will store as GMT+0.  Any client with a time zone other than GMT+0 will show the event on the wrong day/wrong hour.  The fix client side would be to detect calendar servers that do not support UTC and not try to save the event as UTC to the calandar server.  It does does not offer UTC as a time zone for events that are not All Day Events, why not do this check for All Day Events too?

Work around: Do not upgrade from Lighting 0.8.

Updated

8 years ago
Flags: wanted-calendar1.0?
(Assignee)

Comment 20

8 years ago
All-day events should be stored floating, as discussed often times before. It's wrong to tie a timezone to all-day events. If you want to define a specific 24 hours period, use date-times from 00:00 to 24:00.
Back to the problem w.r.t. WCAP: At least the versions I know don't support floating dates, but always define a timezone, thus the current provider code recalculates to the user's timezone setting.
Please keep in mind that WCAP returns UTC-dates/datetimes adding an X-prop to define the specific timezone. I suspect this has been done for interop: in case a client does not know a specific timezone, it deals with UTC.

(In reply to comment #17)
> -> NEW, I have the same system and this happens to me.
> 
> If you set the time zone of the calendar, that seems to make the problem go
> away.
This again sounds like a server config problem. Lightning/Sunbird is not in charge to fix server settings.

> It sounds like the very last problem (among the many mentioned here) is that
> when the data comes back to Sunbird from the client, the empty timezone causes
> the event to go to GMT+0, which, for most users in the US, would send it into
> "yesterday".
Since there's no DTSTART-TZID returned, the datetime is taken as is, i.e. UTC.

I am setting this back to WORKSFORME. I still don't get about why there's a client-side bug, though I am still open for improvements. Benc and uriahq, could you please make clear what could be fixed client-side?
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Flags: wanted-calendar1.0?
(Reporter)

Comment 21

8 years ago
As the logs from Sunbird in comment #9 show:
https://bugzilla.mozilla.org/show_bug.cgi?id=477307#c9

------------------------------
### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
not a supported timezone: floating

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[context-id: ae6e31df-e3b3-4fd9-9e74-7a359413d3a9, uri: https://xxxxxx.xxx/,
userId=queenux, default calendar]
warning: defaultTimezone: cannot get X-NSCP-CALPROPS-TZID!

### WCAP log entry: 2009/02/10 16:51:00 America/New_York isDate=0
[context-id: ae6e31df-e3b3-4fd9-9e74-7a359413d3a9, uri: https://xxxxxx.xxx/,
userId=queenux, default calendar]
floating not supported, falling back to default: UTC
--------------------------------

The client detects that the server does not support floating time zone and sets the event time zone to a default of UTC.  Why don't the client set the time zone to the value of calendar.timezone.local=America/New_York, or use the timezone of the server icsTimezone=America/New_York? (Comment 12)  When the client sends over a TZ of UTC, why would the server think that it should store it as America/New_York instead of GMT+0?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 22

8 years ago
(In reply to comment #21)
> The client detects that the server does not support floating time zone and sets
No, as I mentioned before: The client expects a timezone to be configured. The "floating" log entry relates to a date-time, thus is unrelated to this problem (Former lightning versions have stored "floating" (which has been a bug yet resolved). To be clear: The server cannot cope with floating dates nor date-times. It will always enforce a timezone for all-day events (DATE values).

> the event time zone to a default of UTC.  Why don't the client set the time
> zone to the value of calendar.timezone.local=America/New_York, or use the
> timezone of the server icsTimezone=America/New_York? (Comment 12)  When the
> client sends over a TZ of UTC, why would the server think that it should store
> it as America/New_York instead of GMT+0?
Because this would be timezone guessing. Make sure your account has a timezone configured and you're fine. We're not going to work around server config problems.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 23

8 years ago
(In reply to comment #22)
> (In reply to comment #21)
> > The client detects that the server does not support floating time zone and sets
> No, as I mentioned before: The client expects a timezone to be configured. The
> "floating" log entry relates to a date-time, thus is unrelated to this problem
> (Former lightning versions have stored "floating" (which has been a bug yet
> resolved). To be clear: The server cannot cope with floating dates nor
> date-times. It will always enforce a timezone for all-day events (DATE values).
> 

I thought "floating not supported, falling back to default: UTC" was the client detecting that the server does not support floating time and the client was setting the Time Zone to UTC.  If that is related to a different bug then having floating events set to GMT+0 instead of configured Time Zone, then I am completely lost.

> > the event time zone to a default of UTC.  Why don't the client set the time
> > zone to the value of calendar.timezone.local=America/New_York, or use the
> > timezone of the server icsTimezone=America/New_York? (Comment 12)  When the
> > client sends over a TZ of UTC, why would the server think that it should store
> > it as America/New_York instead of GMT+0?
> Because this would be timezone guessing. Make sure your account has a timezone
> configured and you're fine. We're not going to work around server config
> problems.

Correct.  The server won't guess that you mean America/New_York when it is told UTC.  Maybe instead of the client falling back to UTC when it can't send over a float time, it should default to the Mozilla Preference 'calendar.timezone.local'.  I would hazard to say that 99.9999999% of the time, the time zone a user sets their desktop client to be is a lot closer of a time zone than UTC.  At least in my setting, the TZ set in the Mozilla client, on the server, and for the account, are set to America/New_York (GMT-4) and not to UTC or GMT+0.  I am under the impression that 'UTC' is hard coded in the Lightening / Sunbird client instead of pulling the value from calendar.timezone.local.
(Reporter)

Updated

8 years ago
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 24

8 years ago
If I'm understanding this correctly, Daniel is saying that Sunbird 0.9 will always send "tzid=UTC"

My question is: what is that supposed to mean? That is not a TZID in the Sun Calendar Server's default timezones.ics file and I'm not sure what entry you would add. (For one thing, it looks more like a "TZNAME" than a "TZID."

There does not seem to be any provision in the WCAP documents for handling this. Is there anything wrong with reverting the WCAP behavior back to the previous version, which worked?
(Assignee)

Comment 25

8 years ago
W.r.t. the tzid parameter: Lightning uses the configured timezone (if there's any, this is really the problem!) and passes this over using the tzid parameter. Albeit dtstart/dtend etc are passed as UTC (trailing Z) date-times in conjunction with the tzid parameter.

W.r.t. to all-day events: the WCAP server cannot cope with floating dates (which all-day event are meant to be, please understand this). Thus to narrow the user's expectation, Lightning passes over the tzid of the configured calendar (again, there's none, this seems to be the problem).

W.r.t. the "floating" timezones (which is really no valid TZID): This has been a bug fixed meanwhile. Has anybody yet had a look at Lightning 1.0pre BTW?

W.r.t. this bug status: From my POV there aren't any new conclusions. Please check the user's configured timezone (e.g. using Calendar Express) and the problem ought to vanish. It's irrelevant to me if the bug gets reopened again and again. I am the code owner of this module, but yet don't see any problem to fix client-side.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 26

8 years ago
(In reply to comment #25)
> W.r.t. the tzid parameter: Lightning uses the configured timezone (if there's
> any, this is really the problem!) and passes this over using the tzid
> parameter. Albeit dtstart/dtend etc are passed as UTC (trailing Z) date-times
> in conjunction with the tzid parameter.

Yes, Lightening gets no configured time zone from the server.
 
> W.r.t. to all-day events: the WCAP server cannot cope with floating dates
> (which all-day event are meant to be, please understand this). Thus to narrow
> the user's expectation, Lightning passes over the tzid of the configured
> calendar (again, there's none, this seems to be the problem).

Exactly.  
 
> W.r.t. the "floating" timezones (which is really no valid TZID): This has been
> a bug fixed meanwhile. Has anybody yet had a look at Lightning 1.0pre BTW?

Yes.  See Comment #4.

> W.r.t. this bug status: From my POV there aren't any new conclusions. Please
> check the user's configured timezone (e.g. using Calendar Express) and the
> problem ought to vanish. It's irrelevant to me if the bug gets reopened again
> and again. I am the code owner of this module, but yet don't see any problem to
> fix client-side.

I have recently been informed how to set the Time Zone that a calendar reports to a WCAP client, and it is in a location that is non-accessible by the administrator.  Apparently this value can only be changed by the user and it must be done for each calendar that the user owns.  Also, this value does not seam to initialize from the TZ set in the user profile for CalExpress or UWC.

Comment 27

8 years ago
I think there are some aspects of the server that could be improved, but I still think that part of the problem is the client side. 

I don't think that the client should be able to use TZID=UTC. Maybe this is just a flaw with the way WCAP is defined, where a server doesn't tell the client it's default timezone, and is allowed to serve up a calendar without a declaring a timezone either... but I don't think the client can send validly send back TZID=UTC.

That value isn't going to be in the list of timezones that the calendar server provides in the response to "get_all_timezones.wcap".

And, from a data-struture perspective, UTC is not a "tzid", it is a "tzname", and that WCAP does not use that type of naming (EST, PDT), etc, because it is not unique.

I am not certain there is a solution to this problem, but I do not think that this should be the default behavior. Is there any reason the WCAP behavior could not simply work as it did in 0.8?
(Assignee)

Comment 28

8 years ago
(In reply to comment #27)
> I don't think that the client should be able to use TZID=UTC. Maybe this is
> just a flaw with the way WCAP is defined, where a server doesn't tell the
> client it's default timezone, and is allowed to serve up a calendar without a
> declaring a timezone either... but I don't think the client can send validly
> send back TZID=UTC.
I slightly disagree here. Users have reported using UTC makes sense, e.g. if you need a DST-less timezone to handle recurring events correctly. In addition, UTC has a value if you need to sync different parties across the world. Using a specific prominent timezone often works, too, but is harder to calculate.

> And, from a data-struture perspective, UTC is not a "tzid", it is a "tzname",
> and that WCAP does not use that type of naming (EST, PDT), etc, because it is
> not unique.
I disagree here, UTC is not a timezone but has value much like GMT has.

> I am not certain there is a solution to this problem, but I do not think that
> this should be the default behavior. Is there any reason the WCAP behavior
> could not simply work as it did in 0.8?
IIRC the behaviour always has been like this.

Anyway, I think this bug is getting off track of its initial description. Properly configuring the timezone (on the server) should help.
(Reporter)

Comment 29

8 years ago
(In reply to comment #28)
> (In reply to comment #27)
 <snip snip>
> > I am not certain there is a solution to this problem, but I do not think that
> > this should be the default behavior. Is there any reason the WCAP behavior
> > could not simply work as it did in 0.8?
> IIRC the behaviour always has been like this.
> 
> Anyway, I think this bug is getting off track of its initial description.
> Properly configuring the timezone (on the server) should help.

The behavior of Lightening/Sunbird 0.8 to 0.9/pre-1.0 changed to to be more stringent with some RFC (I cant remember the number) in which All Day events should be recorded with a Floating time zone.  Unfortunately, if a server does not support Floating time zones the new behavior causes the client to handshake and store the event as UTC/GMT.  As most users do not use GMT as their default time zone, events appear to be recorded on the wrong day.  Client could detect servers that do not follow the RFC so stringently and handshake to use 'calendar.timezone.local' as the default Timezone instead of UTC/GMT.  If this could not be detected, then give an option in the configs (even if you need to use Config Editor) to allow reverting back to 0.8 behavior.

The correct time zone appears to only be set on the server side on a per calendar  basis, post calendar creation.  For example, my UID has 3 calendars, so I have to set my TZ in 3 locations.  I, as the administrator, apparently can not do this for myself as a user. This is both an administrative and a UI nightmare.

From the user perspective, this is why both the client and server are equally at fault.

Comment 30

8 years ago
Daniel, I can would agree that this bug has dragged out, but I don't think it is getting off topic....

Since this is bug discussion on the client side, here's my point about the client.

You can't send "tzid=UTC" for a couple reasons.

1- It isn't a tzid. Sun's product usage lableling tzid's as tzid's isn't externally consistent either, but server uses tzid as the identifier, not tznames. Maybe this is a WCAP-ism, and maybe it is mushy and scattered through the Calendar Server documentation, but the three (and sometimes four) letter acronyms are not used here. "Location/Area" is what I have seen some people refer to it.

2- It isn't on of the tzid's returned when you start your WCAP session. 

You can use UTC as the time zone for the purposes of calculating values in the other fields, but you cannot use that in the tzid parameter. 

http://docs.sun.com/app/docs/doc/819-4654/acakv?l=en&a=view

A WCAP command that includes the time zone ID (tzid) parameter should refer to a valid time zone defined in the timezones.ics file. Calendar Server then returns data using that time zone. If a WCAP command specifies an unrecognized time zone, Calendar Server returns data in the GMT time zone by default.

NOTE: The client gets the information in timezones.ics via the "get_all_timezones.wcap"

As far as I can tell for WCAP, you should never send anything in tzid= that was not in the list you received. The presumption is that the list of time zones on the clients and servers match. (When they do not match, lots of bad things happen...)

Like I said before, maybe this is because WCAP was poorly defined or defined from an earlier spec, and I don't know if other WCAP servers ship with support for a tzid=UTC, but I don't understand how the new logic in 0.9 is better WCAP client behavior than either:

1- The old logic in 0.8
2- uriahq's sugestion that the client simply use its default timzeone -> TZID.

Comment 31

8 years ago
Okay, one final comment: Looking at the zoneinfo database, it seems that, in this namespace, the correct string is "Etc/UTC", not "UTC". That isn't in the calendar server's ics.conf, but it might be possible to fix it.

"
Additionally a special area of Etc is used for some administrative zones, particularly for “Etc/UTC” which represents Coordinated Universal Time.
"

http://en.wikipedia.org/wiki/Zoneinfo#Names_of_time_zones
(Assignee)

Comment 32

8 years ago
Created attachment 416759 [details] [diff] [review]
fallback to local lightning tzid

Guys, even though I still consider this a server config problem (unconfigured user timezone) we could (as a compromise) fall back to Lightning's (locally) configured timezone. If however that tzid is not equally supported by the server, we fall back to UTC.
Assignee: nobody → dbo.moz
Attachment #416759 - Flags: review?(philipp)
(Reporter)

Comment 33

8 years ago
(In reply to comment #32)
> Created an attachment (id=416759) [details]
> fallback to local lightning tzid

I tried the patch added to my Lightening and I am still getting a:
  error: defaultTimezone: cannot get X-NSCP-CALPROPS-TZID!
  Error code: MODIFICATION_FAILED. Description: MODIFICATION_FAILED

in the error console with no event saved onto the server.

> Guys, even though I still consider this a server config problem (unconfigured
> user timezone) we could (as a compromise) fall back to Lightning's (locally)
> configured timezone. If however that tzid is not equally supported by the
> server, we fall back to UTC.

Excellent!  Seeing that non-all day events are not an issue, then this too should not be an issue.  Also, if the users locally configured timezone does not work, the user would know about that as soon as they create their first calender event whether it is all day or not.
(Assignee)

Comment 34

8 years ago
(In reply to comment #33)
> (In reply to comment #32)
> > Created an attachment (id=416759) [details] [details]
> > fallback to local lightning tzid
> 
> I tried the patch added to my Lightening and I am still getting a:
>   error: defaultTimezone: cannot get X-NSCP-CALPROPS-TZID!

That's because the server config is missing. Nonetheless it's only logged.

>   Error code: MODIFICATION_FAILED. Description: MODIFICATION_FAILED

Hmm, I think this is unrelated. Even using &tzid=UTC won't lead to this.

However, what's your local lightning timezone setting? Make sure it fits one of the server's timezone (look for get_all_timezones.wcap in the log).
Comment on attachment 416759 [details] [diff] [review]
fallback to local lightning tzid

r/a=philipp
Attachment #416759 - Flags: review?(philipp) → review+
Comment on attachment 416759 [details] [diff] [review]
fallback to local lightning tzid

comm-1.9.1: http://hg.mozilla.org/releases/comm-1.9.1/rev/10bfd20e6a84

relbranch: http://hg.mozilla.org/releases/comm-1.9.1/rev/1f32ff11083d

comm-central: http://hg.mozilla.org/comm-central/rev/db549abd0e98
(Reporter)

Comment 37

8 years ago
Default local Time Zone is still accepted by server when creating events with start and stop times, but event is no longer saved when event is all day.  Full error messages below.

---------------------------------------

### WCAP log entry: 2009/12/14 14:43:15 America/New_York isDate=0
[context-id: 97e89eff-ba15-4063-9428-377e2e178ec9, uri: https://xxxxxx.xxx/, userId=queenux, calId=queenux@xxxxxx.xxx:TzoneTest]
error: defaultTimezone: cannot get X-NSCP-CALPROPS-TZID!
stack:
1: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapUtils.js:167] logError
2: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapCalendar.js:329] calWcapCalendar_defaultTimezoneGetter
3: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapCalendar.js:345] calWcapCalendar_getAlignedTzid
4: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapCalendarItems.js:582] calWcapCalendar_storeItem
5: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapCalendarItems.js:694] calWcapCalendar_adoptItem
6: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calWcapCalendarItems.js:703] calWcapCalendar_addItem
7: [null:0] null
8: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calTransactionManager.js:194] cT_doTransaction
9: [null:0] null
10: [file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calTransactionManager.js:69] cTM_createAndCommitTxn

-------------

Warning: There has been an error reading data for calendar: Time Zone Test.  However, this error is believed to be minor, so the program will attempt to continue. Error code: 0x80004005. Description: NS_ERROR_FAILURE

------------------------
Error: An error occurred when writing to the calendar Time Zone Test! Error code: MODIFICATION_FAILED. Description: MODIFICATION_FAILED
Source File: file:///home/queenux/.thunderbird/6sgc94av.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calCalendarManager.js
Line: 952
(Assignee)

Comment 38

8 years ago
Again, I've left the log entry in since it's showing a server config problem. But if your lightning timezone is supported by the server, it's used instead of UTC, i.e. it's a better fallback. Creating all-day events of course works for me.
(Reporter)

Comment 39

7 years ago
In case anyone cared (or didn't migrate away from CS5), the real fix became available Feb 2010.

Calendar Server SunOS 5.9_x86 5.10_x86: Core patch
Patch 121658-41
Xref: This patch is available for Solaris sparc in patch 121657-41, and for Linux in patch 121659-41
6889953 Missing X-NSCP-CALPROPS-TZID provision might result in wcap client missbehavior

Description: 

During user provisioning on Calendar Server Side X-NSCP-CALPROPS-TZID will not be setup for new user, this result in WCAP client missbehavior, like Lightning or Evolution (as those clients only related on WCAP information and not on user LDAP information).
Resolution: WORKSFORME → FIXED
You need to log in before you can comment on or make changes to this bug.