Closed Bug 339960 Opened 18 years ago Closed 17 years ago

event editor adds 2 hours to time when saving to webdav

Categories

(Calendar :: Provider: ICS/WebDAV, defect)

Product:
Calendar
Component:
Provider: ICS/WebDAV
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: jmask, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Sunbird/0.3a2

when saving an event the time is moved 2 hours to future. for me it looks like the server provides and expects gmt time. when loaded the time is converted to local time. but when saving the time isn´t converted back to gmt. i might be wrong ^^
that only happens with a webdav calender, for local it work fine...

Reproducible: Always

Steps to Reproduce:
webdav server is openXchange. maschin and sunbird timezone is europe/berlin.
when adding or editing an event the edit window shows the same time than the overview. after saving the event the overview still shows the entered time. after reloading the webdav calender the event is moved 2 hours to the future
Is this webdav or caldav?  You say webdav in the summary, but have filed it in the caldav component.
sorry its webdav
Component: CalDAV provider → Base
The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!
QA Contact: caldav-provider → base
Component: Internal Components → Provider: ICS/Webdav
QA Contact: base → ics-provider
Reporter, can you re-test with a recent nightly build?  I suspect this bug has been fixed.
Keywords: qawanted
Jason,
can you please attach an ics-file to this bug were you see this happening?
If you dont have access to the original ics file than you also can export your subscribed calendar to ics using sunbird/lightning.
Thanks.
as the only calendar i have access to is my own and it is in real use i prefere to do not add the whole file but here comes the as far as i can judge relevant part:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:OPEN-XCHANGE
BEGIN:VEVENT
CLASS:PUBLIC
CREATED:20070212T093738Z
DTSTART:20070213T170000Z
LOCATION:testttttttt
ORGANIZER:mailto:jmask@gmx.de
DTSTAMP:20070212T094413Z
STATUS:CONFIRMED
SUMMARY:test
TRANSP:OPAQUE
UID:61378@groupware.server
DTEND:20070213T180000Z
ATTENDEE:mailto:jmask@gmx.de
END:VEVENT
END:VCALENDAR

i added the entry to start at 17:00 and when it is read back from the server its listed at 18:00. so by now its only 1 houre decay but still to mutch :)
on my usual interface (ox webinterface) it is also shown at 18:00 so the discrepancy must come by setting the data...

i hope that helps so fare...

cu jason
i captured the put data from sunbird to oxchange
here comes the output:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20070212T093700Z
LAST-MODIFIED:20070212T103718Z
DTSTAMP:20070212T103718Z
UID:857540df-593a-45af-9eef-e1cab5bb2509
SUMMARY:test
STATUS:CONFIRMED
CLASS:PUBLIC
ORGANIZER:mailto:jmask@gmx.de
ATTENDEE:mailto:jmask@gmx.de
DTSTART;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070213T170000
DTEND;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070213T190000
TRANSP:OPAQUE
LOCATION:testttttttt
END:VEVENT
BEGIN:VTIMEZONE
TZID:/mozilla.org/20070129_1/Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

as i could read the time is send correctly so it seams to be a problem of oxchange when the data is received. could there be a relation to the vtimezone part in the send data or should i just complain to the oxchange guys? :)

hope you´ll find an answer

cu jason
Hi, 
I tried to reproduce this error with my OX5 system [OX SP 1 installed on a SLES 9] and Sunbird 0.3.1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20070213 Sunbird/0.3.1) on a Win XP system. I can confirm a shift by one hour. 

I set up a new calendar folder on the OX system and did the following: 
1) Accessed the server from the Sunbird client via http://server/servlet/webdav.ical?calendarfolder=1628

2) Created an event with time settings "start: 18:00 " and "end: 19:00". 

3) Exported that event to an ics-file 
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20070310T215431Z
LAST-MODIFIED:20070310T215446Z
DTSTAMP:20070310T215446Z
UID:47631e1b-9590-4dcf-81ab-10edaf4def3b
SUMMARY:test app
DTSTART;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070310T180000
DTEND;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070310T190000
END:VEVENT
BEGIN:VTIMEZONE
TZID:/mozilla.org/20070129_1/Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

As you can see 
DTSTART;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070310T180000
DTEND;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070310T190000
correspond exactly to the Sunbird display. 

4) I checked the event on the server -> there it is shown with a start time 
"start: 19:00" and an "end: 20:00". 

5) I reloaded the remote calendar in Sunbird and exported the remote calendar to an ics file: 
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20070310T215532Z
LAST-MODIFIED:20070310T220202Z
DTSTAMP:20070310T220156Z
UID:47631e1b-9590-4dcf-81ab-10edaf4def3b
SUMMARY:test app
STATUS:CONFIRMED
CLASS:PUBLIC
ORGANIZER:mailto:ralph.moenchmeyer@anracona.de
ATTENDEE:mailto:ralph.moenchmeyer@anracona.de
DTSTART:20070310T180000Z
DTEND:20070310T190000Z
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

!!! Note that the start time is 18:00 and the end time is 19:00 in the ics export. However, the event is displayed in the Sunbird calendar from 19:00 to 20:00 !!!
I find this strange. 

6) I exported the event to an ics file: 
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20070310T215532Z
LAST-MODIFIED:20070310T220202Z
DTSTAMP:20070310T220156Z
UID:47631e1b-9590-4dcf-81ab-10edaf4def3b
SUMMARY:test app
STATUS:CONFIRMED
CLASS:PUBLIC
ORGANIZER:mailto:ralph.moenchmeyer@anracona.de
ATTENDEE:mailto:ralph.moenchmeyer@anracona.de
DTSTART:20070310T180000Z
DTEND:20070310T190000Z
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


Summary: The exported ics data show the correct start and end points in time. However, on the server the event is registered one hour later. In addition, after a reload of the calendar in Sunbird the event is displayed with a shift of one hour whereas the ics exports still show the original start and end points in time. 

The server clock on the OX server (SLES 9 based) is in my case set to "local time" and not to UTC/GMT. The XP client is synchronized with the server via NTP.  

If you need any more information - just ask. 
  
Regards
Ralph 

P.S.: The problem reminds me of a similar situatiion I had last year with KDE KOrganizer. If I remember correctly the KOrganizer problem was the reason why I changed the server clock on the server from UTC/GMT to local time. With my present installation of KDE Kontact/Korganizer I have no problems with the OX server.      
(In reply to comment #8)
> DTSTART;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070310T180000
> DTEND;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070310T190000

> 4) I checked the event on the server -> there it is shown with a start time 
> "start: 19:00" and an "end: 20:00". 
> 
> 5) I reloaded the remote calendar in Sunbird and exported the remote calendar
> to an ics file: 
> DTSTART:20070310T180000Z
> DTEND:20070310T190000Z

SO it looks like the server remove the timezone information, and put the event into GMT (that's the Z at the end), but did not change the time. The effect is that the server moved the event one hour. So I blame the server for loosing data.
i just added a short description and a link to this bugreport to the openxchange-bugzilla:
http://www.open-xchange.org/bugzilla/show_bug.cgi?id=6386

please feal free to add further comments and to find out whether sunbird has to send the data differently by definition or this is a bug of ox.

cu & thx jason
Hi, 
just an additional comment: 
I have set the internal server clock to UTC/GMT now - just to see whether this may have an influence. In the configuration I described in comment 8 the server clock was set to local time. 
So the BIOS time is now UTC (e.g. 11:36), as it should be for Linux systems. My timezone parameters on the SLES 9 Linux Server are set to MEZ (Germany, Berlin -> UTC + 1 hour) - and the server correctly displays 12:36.
So SLES 9 handles the time difference between the BIOS clock time and the local timezone correctly. 

I first checked again with KDE Kontact/Korganizer whether calendar events generated by the Korganizer client show any time shift. Answer: No time shift. 

Then I retested Sunbird as in comment 8. Same result - one hour shift. 

So the question really is why the server regards the event time delivered by Sunbird as UTC time (Z). This may be a server bug as assumed in comment 9. But can you really exclude Sunbird errors in the data transmission from and to OX? 

I think, a reasonable next step would be to ask the KDE developers whether they made special adjustments for OX severs in their interface.   

Regards
Ralph 
Looking at the comments in the openXchange bug referenced in comment 10, the fault lies entirely on the side of OX.

As there's really nothing we can do about this from our side, I'm marking this bug as INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Keywords: qawanted
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.