calendar.createEvent saved time mismatch

[ezanella]

To reproduce follow these steps:

1. Set phone on Amsterdam/Berlin/Rome timezone.
2. Create calendar event:

evt1 = calendar.createEvent({
"summary": "Test Summary",
"start": new Date("Mar 21, 2013, 15:00"),
"end": new Date("Mar 21, 2013, 17:00"),
"description": "Test Description",
});

On device Calendar this event starts at 16:00 and ends at 18:00. WRONG!

1. Create another calendar event:

evt2 = calendar.createEvent({
"summary": "Test Summary",
"start": new Date("Apr 01, 2013, 15:00"),
"end": new Date("Apr 01, 2013, 17:00"),
"description": "Test Description",
});

On device Calendar this second event starts correctly at 15:00. CORRECT!

On March 31st there will be DST change in Europe, while in the US it has already been changed on March 10th. Is this related to this bug?

What is wrong with timezone/DTS handling?

[lsale]

Tested on 10.0.10.X and above by calling createEvent without specifying the timezone I get

Timezone :::::::::::::::::::: Results
+1 W.Central Africa 15:00
+1 Sarajevo 16:00
+1 Brussel/Paris 16:00
+1 Belgrade 16:00
+1 Amsterdam 16:00
+2 Cairo 15:00

This is happening for any event created between the 10th and 31st of March. From my tests the only +1 time that is not affected by this bug is the W. Central Africa due to the fact they don't observe the daylight saving time.

[ejzn]

This is probably a native side issue unless @rwmtse knows of anything specifically? But id you've dug through the native code and don't see anything it might be a bug with the actual Contacts service on device.

[rwmtse]

I took a look at the code. I can't spot what causes this issue. The code that I use for figuring out the timezone is pretty much the same code used in the Calendar app (which uses <unicode/timezone.h>):
https://github.com/blackberry/BB10-WebWorks-Framework/blob/next/ext/pim.calendar/native/pim_calendar_qt.cpp#L592
https://github.com/blackberry/BB10-WebWorks-Framework/blob/next/ext/pim.calendar/native/timezone_utils.cpp

[ejzn]

@ezanella please file a pr to track this internally and get some support from the calendar team.

[lsale]

@erikjohnzon @rwmtse PR 321994 has been created

[ejzn]

No use keeping this open. We have no control. PR is created. Close.

[jeffheifetz]

I would disagree, this is public visibility into when the issue will be fixed.

[lsale]

This issue can be now closed.
@dylin has opened pull request 653 to address this #653