Bug 6933 - (int-153248) Alarm times are shown wrong
(int-153248)
: Alarm times are shown wrong
Status: REOPENED
Product: Calendar
General
: 5.0/(3.2010.02-8)
: All Linux
: Low normal with 4 votes (vote)
: ---
Assigned To: unassigned
: calendar-general-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-12-13 22:34 UTC by Marcin Juszkiewicz
Modified: 2014-03-08 10:41 UTC (History)
6 users (show)

See Also:


Attachments
Example of how badly event looks (34.71 KB, image/png)
2009-12-13 22:36 UTC, Marcin Juszkiewicz
Details
Example event (3.81 KB, text/plain)
2010-01-14 19:12 UTC, Marcin Juszkiewicz
Details
Example event moved to 15th January 2015 (3.80 KB, text/plain)
2010-03-24 14:11 UTC, Marcin Juszkiewicz
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Marcin Juszkiewicz (reporter) 2009-12-13 22:34:09 UTC
SOFTWARE VERSION:
1.2009.42.11

EXACT STEPS LEADING TO PROBLEM: 
1. Get other device (I used S60 phone) and create entry with alarm "1:45"
before event
2. Import it into calendar (I used BT transfer sync on first boot)
3. Check how calendar display event.

EXPECTED OUTCOME:
"Alarm 1:45 before" shown

ACTUAL OUTCOME:
"Alarm 3h before" is shown.

REPRODUCIBILITY:
always

OTHER COMMENTS:
I have no idea why it can not be shown in proper way. I understand that alarm
time can not be entered in such way but it should be shown proper. Especially
when they work at 1:45 before event not 3:00 before like it is on a screen.
Comment 1 Marcin Juszkiewicz (reporter) 2009-12-13 22:36:40 UTC
Created an attachment (id=1754) [details]
Example of how badly event looks
Comment 2 Andre Klapper maemo.org 2009-12-16 03:45:45 UTC
Thanks for reporting this.

Assuming it is an ics file, can you attach it here (and remove any confidential
data before)?
There is a similar internal ticket that was fixed after the release of
1.2009.42-11 (int-139650).
Comment 3 Fredrik Wendt 2010-01-11 19:10:40 UTC
Andre: Does this mean that you can now set the alarm to not just the predefined
"offsets", but to whatever you actually like it to be?
Comment 4 Marcin Juszkiewicz (reporter) 2010-01-14 14:13:48 UTC
(In reply to comment #3)
> Andre: Does this mean that you can now set the alarm to not just the predefined
> "offsets", but to whatever you actually like it to be?

no, 51-1 still has only fixed amounts available :(
Comment 5 Andre Klapper maemo.org 2010-01-14 17:51:20 UTC
Can somebody please attach an example ics file (?) here as a testcase please?
From which exact S60 phone has this been imported?
Comment 6 Marcin Juszkiewicz (reporter) 2010-01-14 19:12:29 UTC
Created an attachment (id=1977) [details]
Example event

This is event created in KOrganizer. After importing it into Calendar I see
wrong alarm time (3h before instead of 1:45 before).

And S60 phone was Nokia E66 with v210.xx.xx firmware - event was created in
Handy Calendar.
Comment 7 Andre Klapper maemo.org 2010-01-14 21:37:24 UTC
"Please let us know your exact device name and also please check time zone of
your S60 phone"
Comment 8 Marcin Juszkiewicz (reporter) 2010-01-15 08:20:52 UTC
(In reply to comment #7)
> "Please let us know your exact device name

"Nokia E66 with firmware v210.xx.xx" - wrote it already

> and also please check time zone of your S60 phone"

Same as N900 time zone.

But what does time zone has to definitely wrong displaying of alarm time?
Example event was created in KOrganizer (KDE 4.3.4 from Debian 'sid' packages
and same time zone as my N900 - adding that info just in case) and after import
to N900 'so called' Calendar it is still displayed wrong.
Comment 9 Venomrush 2010-03-23 23:09:44 UTC
Closing as WORSKFORME for the time being, as I cannot reproduce the issue, I
tried on another S60 device (N97), but please feel free reopen if this happens
again and if possible please provide exact steps leading to the issue.
Comment 10 Andrew Flegg maemo.org 2010-03-24 13:49:14 UTC
I've just saved icalout2.ics to my N900 (about product says 2.2009.51-1; but it
has been updated to 3.2010.02-8):

* Download icalout2.ics to MyDocs
* Open File Manager
* Launch icalout2.ics
* Import into first calendar
* Look at event (2010-01-15)

I don't see *any* alarm information:

--------8<-------
Test event which will have alarm set to 1:45
-------
Friday 15 January 2010
From 08:30 to 10:30

N900 (Local)
-------->8--------
Comment 11 Marcin Juszkiewicz (reporter) 2010-03-24 14:08:45 UTC
(In reply to comment #10)
> I've just saved icalout2.ics to my N900 (about product says 2.2009.51-1; but it
> has been updated to 3.2010.02-8):
> 
> * Download icalout2.ics to MyDocs
> * Open File Manager
> * Launch icalout2.ics
> * Import into first calendar
> * Look at event (2010-01-15)
> 
> I don't see *any* alarm information:

Calendar does not shows alarm information for past events. I am now testing
event in 2015 just to give example which will work for sure before nokia 'so
called developers' will fix issue.
Comment 12 Marcin Juszkiewicz (reporter) 2010-03-24 14:11:27 UTC
Created an attachment (id=2519) [details]
Example event moved to 15th January 2015

As calendar on n900 does not display alarm informations for past events I moved
testing example event to 15th January 2015 to give devs a chance to make it
fixed.
Comment 13 Marcin Juszkiewicz (reporter) 2010-03-24 14:12:07 UTC
Confirmed as still existing in PR 1.2 Calendar (x86 SDK).
Comment 14 Andrew Flegg maemo.org 2010-03-24 14:16:35 UTC
Confirmed. Reproduced using the steps as above.

The ics file contains: TRIGGER;VALUE=DURATION:-PT1H45M

Whereas the event is shown in the Calendar as:

--------8<---------
Test event which will have alarm set to 1:45
----
Thursday 15 January 2015
From 08:30 to 10:30

Alarm 3 hours before

N900 (Local)
-------->8---------
Comment 15 Robin Lee Powell 2010-11-08 22:48:48 UTC
The issue here is probably Maemo's unfortunate handling of "allowed" alarm
times; see https://bugs.maemo.org/show_bug.cgi?id=11556

-Robin
Comment 16 Marcin Juszkiewicz (reporter) 2010-12-08 18:35:12 UTC
Nokia ended supporting Maemo5 and this application source code is not
available. No one will fix it so I close bug.
Comment 17 Andre Klapper maemo.org 2010-12-08 20:05:50 UTC
Marcin: Though you might be correct I prefer to close bug reports as WONTFIX
after getting a Nokia WONTFIX statement (if that will ever happen is a
different question). Hence restoring state. It's up to management (and maybe
involved developers) to decide about WONTFIXes.