In this post I would be focusing on the work done in the past two weeks.
This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/akshayagarwal007/2017-08-11_gsoc_2017_calendar_app_weekly_report_6/
A reminder in case it was overlooked: event scheduling should have ‘smart’ recurrences in addition to the specified YY/MM/DD selections (with optional recurrence):
[ul][li] every day[/li]
[li] every weekday[/li]
[li] every weekend[/li]
[li] every (checkboxed set of days)[/li]
[li] every 1st/2nd/3rd/4th/5th (weekday) of every month[/li]
[li] every MM/DD[/li]
[/ul]It adds complexity, but would make it easy for people to schedule odd-ish events.
Another possible addition would be to add timed computer tasks (much like cron’s operations). For example, instead of just texting you a reminder to start the weekly backup of your file server, it could kick off an ssh session that starts (and logs) the backup.
These are ideas for future implementation, not for immediate attention.
Goal reached! Found some bugs! And much more your App works!
Thank you for your work!
Just a side note, because everyone gets this wrong:- remember that past events that happened, happen in a time zone, and at a point in time, identifiable by a UTC timestamp and a TimeZone name, plus current offset combination.
Future, planned events however, are going occur at a particular planned time, but only “have happend” once that time has actually been reached in that time zone. Imagine you plan something for 9am in 6 months time, and then all of a sudden, the government of your country decides to move their clocks forward or back on a different day than usual. If that future event had been planned to occur at a particular time UTC according to your current local time zone, then the acutal offset could have slipped or gain time, once the actual time arrives.
Now - if the planned event has been set to repeat itself exactly N hours or minutes in the future, you will want (in code) to ignore time zone changes that may occur and just count linear time since the last time the event /actually/ occurred. If however the event should occur “once per week at 9am”, your user is probably expecting 9am to mean 9am, whatever the current daylight savings time setting, and the difference between those two 9am slots didn’t need to be a fixed period of time.
Hopefully I have articulated that well enough to be making sense.