Active Topics
-
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 4 hrs, 50 mins ago -
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 8 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 21 hrs ago -
n770 youtube video (0)
to General by nmdv - 5 days, 20 hrs ago - more...
|
2014-09-11
, 17:49
|
|
Posts: 16 |
Thanked: 14 times |
Joined on May 2012
|
#152
|
Originally Posted by anab
Is there anybody who can help me out with that?
Ouestion regarding the birthday events:
How to set an alarm e.g. 09:00 at the same day of the birthday for every year?
| The Following User Says Thank You to anab For This Useful Post: | ||
 |
|
2014-09-11
, 17:59
|
|
Posts: 505 |
Thanked: 665 times |
Joined on Oct 2009
|
#154
|
Originally Posted by gidzzz
Things I like about Qalendar #665: the dev response time...
It is my fault, corrected in Qalendar 0.9.5:
- Fixed a regression that prevented end time of events from being set properly.
- Updated the German translation.
__________________
Want to know how to add public holidays to your device calendar? See the instructions wiki page.
Want to improve the location bar's search capabilities? there's a wiki page for that too...
Want to know how to add public holidays to your device calendar? See the instructions wiki page.
Want to improve the location bar's search capabilities? there's a wiki page for that too...
Last edited by TomJ; 2014-11-24 at 14:53.
|
|
2014-10-02
, 08:29
|
|
Posts: 203 |
Thanked: 445 times |
Joined on Mar 2010
|
#155
|
I've now finally had the opportunity to test and make use of the new timezone feature.
It works perfectly.
Previously, I often got confused about appointment times across timezones, now I have to remember not to remember!
Thank you!
It works perfectly.
Previously, I often got confused about appointment times across timezones, now I have to remember not to remember!
Thank you!
|
|
2014-10-17
, 14:43
|
|
Posts: 30 |
Thanked: 89 times |
Joined on Jan 2009
|
#156
|
I think I found a bug. Well it's not clear if this bug is with qalendar, nokia or anyone/anything else but something is odd:
I have an event, created ages ago, that repeats every week at a specific time. I'm syncing my N900 calendar via syncevolution (CalDAV) with an ownCloud instance. I'm syncing that with some other software (eM Client, also CalDAV). In eM Client this event is shown one hour off during summer... This is not how I wanted it. On my N900 it's fine.
I started investigating and found this:
When I export the whole calendar via qalendar that event does not have any time zone information. If I understand the RFC regarding time zone identifiers correctly this is not allowed unless you want it to be a "floating time" event. I quote:
Even more clearly:
I do not know how the calendar DB of N900 works but as you (the glorious and gracious creator of qualendar - I can't thank you often enough for creating this wonderful piece of software) stated before it is possible to set time zones and you implemented it and it seems to work fine. So I think there are at least two possibilities:
It seems somehow the export has to be fixed.
Did I misunderstand anything? Or is there an error in reasoning?
Edit: I wanted to create an example file but I somehow failed. The attached file can be imported to e.g. eM Client. (Rename to .ics!) It shows the behavior of a "floating time" event: It occurs on a different time when DST is active/inactive. Unfortunately I can't import that file with qualendar. It just says "An error occured".
Last edited by deryo; 2014-10-17 at 15:04. Reason: Added a file
I have an event, created ages ago, that repeats every week at a specific time. I'm syncing my N900 calendar via syncevolution (CalDAV) with an ownCloud instance. I'm syncing that with some other software (eM Client, also CalDAV). In eM Client this event is shown one hour off during summer... This is not how I wanted it. On my N900 it's fine.
I started investigating and found this:
When I export the whole calendar via qalendar that event does not have any time zone information. If I understand the RFC regarding time zone identifiers correctly this is not allowed unless you want it to be a "floating time" event. I quote:
This parameter [TZID] MUST be specified on the "DTSTART", "DTEND", "DUE", "EXDATE", and "RDATE" properties when either a DATE-TIME or TIME value type is specified and when the value is neither a UTC or a "floating" time.
The use of local time in a DATE-TIME value without the "TZID" property parameter is to be interpreted as floating time, regardless of the existence of "VTIMEZONE" calendar components in the iCalendar object.
- Nokia didn't care about time zones and so if not explicitly set a calendar entry does not have a time zone. The export is "correct", but in stock calendar and qalendar it is interpreted "wrongly" (but consistent) as it should be a "floating time" event.
- All calendar entries do have a time zone but the export does not correctly handle that. I don't know exactly where syncevolution gets its data from but this has to be as broken as the stock calendar/qalendar export is possibly broken. Or is it all the same because all use the calendar backend?
It seems somehow the export has to be fixed.
Did I misunderstand anything? Or is there an error in reasoning?
Edit: I wanted to create an example file but I somehow failed. The attached file can be imported to e.g. eM Client. (Rename to .ics!) It shows the behavior of a "floating time" event: It occurs on a different time when DST is active/inactive. Unfortunately I can't import that file with qualendar. It just says "An error occured".
Last edited by deryo; 2014-10-17 at 15:04. Reason: Added a file
|
|
2015-02-05
, 09:50
|
|
Posts: 287 |
Thanked: 618 times |
Joined on Jan 2011
@ Estonia
|
#157
|
Just noticed one strange thing about reccurring events. I have an monthly event on it's every first Wednesday. So I created an event repeating monthly, interval 1, Forever, By day of week: Wed, By day of month: From beginning: 1 2 3 4 5 6 7. The event is now displayed correcty on every month's first Wednesday except when the Wednesday is the first day of the month - in that case it is not displayed by some strange reason. To check it further I created an test event that shoud repeat at every Wednesday 1st (like that Friday 13th rule in first post) and it just does not repeat at all... Any ideas? Bug?
Last edited by acrux; 2015-02-05 at 10:09.
Last edited by acrux; 2015-02-05 at 10:09.
 |
|
2015-02-18
, 15:01
|
|
Posts: 282 |
Thanked: 2,387 times |
Joined on Sep 2011
|
#158
|
Originally Posted by deryo
Some details are wrong, but you are right about the root of the problem.
Did I misunderstand anything? Or is there an error in reasoning?
Originally Posted by deryo
"Floating" means not bound to any time zone, so floating 20:00 will always be 20:00, no matter if DST is in effect or if you travel around the globe (BTW: calendar-backend does not seem to support that concept).
The attached file can be imported to e.g. eM Client. (Rename to .ics!) It shows the behavior of a "floating time" event: It occurs on a different time when DST is active/inactive.
Originally Posted by deryo
But the attached file (and it appears to be the same for all files exported by calendar-backend) does have time zone information. That information is the "Z" at the end of a DATE-TIME value, which means it is UTC and "TZID" is then forbidden. The time of the event in the attached file varies between DST and non-DST in your time zone because DTSTART is specified in UTC and according to RFC 2445/5545:
When I export the whole calendar via qalendar that event does not have any time zone information. If I understand the RFC regarding time zone identifiers correctly this is not allowed unless you want it to be a "floating time" event.
Information, not contained in the [recurrence] rule, necessary to determine the various recurrence instance start time and dates are derived from the Start Time ("DTSTART") component attribute.
Originally Posted by deryo
This is right. calendar-backend should use local time and TZID with a reference to VTIMEZONE instead of UTC format.
I guess it's possibility no. 2 because in the exported calendar before each BEGIN:VEVENT is a BEGIN...END:VTIMEZONE. The only problem is that the timezone is not used within the VEVENT.
Originally Posted by acrux
This looks like a bug to me, and just like with deryo's report, not caused by Qalendar, but by calendar-backend. You can work around this by simplifying your rule to explicitly say "every first Wednesday". Set the rule to "FREQ=MONTHLY;BYDAY=1WE" (use the plus button under the Wednesday button).
Just noticed one strange thing about recurring events. I have an monthly event on it's every first Wednesday. So I created an event repeating monthly, interval 1, Forever, By day of week: Wed, By day of month: From beginning: 1 2 3 4 5 6 7. The event is now displayed correctly on every month's first Wednesday except when the Wednesday is the first day of the month - in that case it is not displayed by some strange reason. To check it further I created an test event that should repeat at every Wednesday 1st (like that Friday 13th rule in first post) and it just does not repeat at all... Any ideas? Bug?
I have been planning a code review for calendar-backend for a long time, because when working on Qalendar I have stumbled upon more bugs than just the two recently reported, but after investigating various peculiarities of calendar-backend along the way I came under the impression that the code is a mess and I am not eager to touch it, so I do not know when and if I will be doing this... but the issue reported by deryo shows that exported recurring events are terribly broken and it would be really nice to have it fixed.
Meanwhile, there is a small update for Qalendar, 0.9.6:
- Swipe left/right in the event window for next/previous event.
- New translation: Slovenian by sponka.
- Updated translations.
__________________
My Thumb mini-repository: http://gidzzz.mooo.com/maemo/.
My Thumb mini-repository: http://gidzzz.mooo.com/maemo/.
| The Following 15 Users Say Thank You to gidzzz For This Useful Post: | ||
|
|
2015-02-18
, 16:18
|
|
Posts: 505 |
Thanked: 665 times |
Joined on Oct 2009
|
#159
|
Originally Posted by gidzzz
WInner! I had been hoping for that.
Meanwhile, there is a small update for Qalendar, 0.9.6:
- Swipe left/right in the event window for next/previous event.
__________________
Want to know how to add public holidays to your device calendar? See the instructions wiki page.
Want to improve the location bar's search capabilities? there's a wiki page for that too...
Want to know how to add public holidays to your device calendar? See the instructions wiki page.
Want to improve the location bar's search capabilities? there's a wiki page for that too...
|
|
2015-02-20
, 02:26
|
|
Posts: 282 |
Thanked: 2,387 times |
Joined on Sep 2011
|
#160
|
Yet another small update, Qalendar 0.9.7:
- Support for keyboard input in date and time pickers.
- Added a button to date and time pickers to select current date/time.
__________________
My Thumb mini-repository: http://gidzzz.mooo.com/maemo/.
My Thumb mini-repository: http://gidzzz.mooo.com/maemo/.
My Thumb mini-repository: http://gidzzz.mooo.com/maemo/.