When giving the option for something to reoccur every certain amount of time how should I treat times that don't reoccur on every interval?
For example what should happen to birthday reminders for February 29th? Or if I have a monthly appointment on the 31st what should happen on months that do not have a 31st day?
What do you believe the reasonable user would expect and be least surprised by?
My first reaction to this question would be to give the user the option of what to do if it falls on that date (go to next day, skip the day, etc.).
But to directly answer your question, I believe the reasonable user would be least surprised by the occurrence falling on the day before the "skipped" day.
I'd think you would be able to flag dates like this pretty easily. The only dates I can think of are the 29th, 30th, and 31st of a month, or February 29th.
When the user opts to be reminded of one of these dates monthly (or annually for Feb. 29), you can prompt them for an alternate date for those months.
Additionally, you could have an option to be notified "on the last day of each month."
Ideally, prompt when creating the reminder.
If you are stuck with it, I would pull them forward. That's the least harmful choice. You don't always want the least surprise, minimizing the harm of making the wrong choice is also important.
Related
For example, Foo Holiday is the 3rd Tuesday in March. Bar Holiday is the 7th minute of the 7th hour of the 7th day of the 7th Month.
I have looked at standards like ISO8601 but it seems those are more concerned with explicit points in time.
As AlexApps99 described in their answer,
there is no standard that will cover all holidays.
For example, the start of Ramadan often depends on physically sighting the new moon, so it's impossible to predict the exact date, as cloudy weather might prevent anybody from spotting it in your country for a few days.
However, for many repeating events the follow simpler rules (e.g. Foo & Bar Holiday in your question), there is
iCalendar's RRULE (Recurrence Rule),
which is a standard for creating repeating patterns for recurring events.
Many calendar apps will have a GUI for creating RRULE.
RRULE is documented in
RFC 5545 Section 3.8.5.3.
For example, an event for U.S. Presidential Election day would be:
Every 4 years, the first Tuesday after a Monday in November, forever (U.S. Presidential Election day):
DTSTART;TZID=America/New_York:19961105T090000
RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,5,6,7,8
Example taken from RFC 5545 Section 3.8.5.3 Page 129
Foo Holiday (3rd Tuesday in March) could be described with:
RRULE;FREQ=YEARLY;BYMONTH=3;BYDAY=TU;BYMONTHDAY=15,16,17,18,19,20,21
Bar Holiday could be described with (7th minute of the 7th hour of the 7th day of the 7th Month) could be described with:
RRULE;FREQ=YEARLY;BYMONTH=7;BYMONTHDAY==7;BYHOUR=7;BYMINUTE=7
Unfortunately, the iCalendar RRULE spec can't can't handle more complicated rules.
Easter can't be done, (although https://github.com/sappjw/calendars contains Easter RRULEs accurate for
1900-2099, and the Python dateutil library's RRULE has an unofficial extension called BYEASTER, but even then, it only supports Western Easter).
Non-Gregorian calendars are also not supported, however, there is a
draft spec RFC7529 that adds
RRULE support for additional calendars, which would allow you to describe
Chinese New Year using the following syntax:
DTSTART;VALUE=DATE:20130210
RRULE:RSCALE=CHINESE;FREQ=YEARLY
SUMMARY:Chinese New Year
These define a recurring event for the Chinese New Year, with the
first instance being the one in Gregorian year 2013.
Example taken from RFC7529#Section 4.3.1
There's no standard way to represent holidays, because holidays are pretty hard to keep track of. Each country has their own set of holidays, and there are different definitions for what is considered a holiday (public holidays, school holidays, religious holidays, international hotdog day etc).
On top of that, the days that holidays lie on is pretty hard to predict. Many holidays celebrating events on the non-Gregorian calendar, such as Easter, will be on a different date each year, and others based on external events can be unpredictable into the future.
Many holidays are not just "days", but a range multiple days, or specific hours of a day, and you can't forget that these intervals have timezones attached too (and will be different in different countries)
With all this complexity, you'll need to create your own way to represent these holidays, probably ignoring some of the complexity you don't need to handle.
If you're sharing this data, a standard format such as iCalendar would be ideal, and you could store custom properties of the holidays in extension fields (starting with X-).
If you're just storing this data internally, you're better off making your own structure to store whatever you need, perhaps using ISO8601 to store the intervals.
I'm trying to get Dialogflow to report sales in different time periods. When I ask things like
what's the sale last month
what's the sale in march 2011
They work fine. However, if I didn't specify "last" or year, Dialogflow always think I'm asking about the upcoming period (which I guess works great for restaurant booking, etc.). For example, "what was our sale in april" would guess that I mean April of next year.
Should I write a fulfillment to deal with this or is there a way to specify only historical periods only?
Another related question is it has trouble understanding notations like 2010q1 or q2/2015 which is quite common in economics and finance. "q1/2000" would extract only q1 (correctly, but with the upcoming q1). "2000q1" wouldn't be recognized at all.
Thanks!
Is it possible to specify an event to occur on the 1st weekend day of multiple months every 2 years in a single RRULE? Using February and September as a test case, my first thought was:
FREQ=YEARLY;DTSTART=20140320T070000Z;INTERVAL=2;BYSETPOS=1;BYMONTH=2,9;BYDAY=SA,SU
but BYSETPOS reduces the set down to February only. I thought changing the freq to monthly would do the trick after I posted here, but applying an interval of 2 for every other year messes things up because the interval is applied to a monthly freq instead of a yearly freq.
I made this a new question because I did not include interval in my original question.
I think splitting this into multiple rrules would work, but it would greatly increase the complexity of this area of my app so I was hoping for a single rrule with a yearly freq.
Thanks!
FWIW, and since you mention it as a potential workaround, RFC5545 has removed the ability to have multiple RRULE property in a single VEVENT/VTODO (https://www.rfc-editor.org/rfc/rfc5545#section-3.6.1). It was there in RFC2445.
Then, unless someone finds a very elegant and simple solution, you may be left with something that is so convoluted that most clients will barf on it (don't know how interoperability is important to you).
This leaves you with 2 choices I think:
either use 2 different events (maybe linked with a RELATED-TO property)
or, if you can bound the event to a certain number of instances, represent it as a set of RDATE (or RRULE + RDATE, or RRULE + EXDATE, etc...).
Adding BYSETPOS like this may work as you intend:
FREQ=YEARLY;INTERVAL=2;BYMONTH=2,9;BYDAY=+1SA,+1SU;BYSETPOS=1,3
what you could try is to take advantage of the fact that bysetpos allows you to select within the year the selected instances of your rule, then you could limit the number of instances to the first week of the month (by setting the days of the month to the first 6 ones) to avoid the cases where month have more or less weeks, which then allows you to select the first and third instance in your year.
Which then gives:
DTSTART:20140320T060000Z
FREQ=YEARLY;INTERVAL=2;WKST=MO;BYSETPOS=1,3;BYMONTH=2,9;BYMONTHDAY=1,2,3,4,5,6,7;BYDAY=SA,SU
which will be:
Sat 2014/Sept/6
Sat 2016/Feb/6
Sat 2016/Sep/3
...
Sun 2024/Sep/1
this was verified with dateutil-python and http://jkbr.github.io/,
For example, take this event:
210489449014070 Facebook Event / Graph API Explorer
This event was created back in September 2011. When it was created, it correctly showed Friday, November 11, 2011 11:11pm as the date and time of the event.
But now, it shows Saturday, November 12, 2011 12:11am as the date. This is also happening for future events, such as 426044564103401.
However, it's not happening for even e.g. in the current month like 330237680381087.
Which show the correct date (same as graph shows.) This one was created a few months ago.
My suspicion is that it's still applying the DST offset to the date. For example, right now, pacific time is 7 hours from UTC (because DST is in effect, thus PDT.) On 2012-11-04, DST will end and it will go back to 8 hours from UTC. It "falls back" in fall.
The date on the frontend of Facebook.com is showing as if it's still using the 7 hour offset (it's an hour ahead of what it should be.) My assumption/guess is that at 2012-11-04 02:00:00, it will begin showing the correct date. Hurray? But at that point, the dates that are correct now will probably show wrong (because it won't apply DST anymore.)
I'm guessing this means that internally, timezone-less events are now treated as "-07:00" or "-08:00" globally, based on the current UTC offset, rather than a date-relative one.
Do I have to pull all 186,272 events and update all of them to use timezone dates to fix this (also impacting frontend display to other users, and possibly impacting other parties that are interfacing with these events via FQL or etc.)?
Thanks for any help.
Was probably an issue when Facebook as migrating towards timezone-less events http://developers.facebook.com/roadmap/completed-changes/
I'm developing an international software that act as a simple project management software and I'm facing a problem. This problem is about date/hour and time zone.
When a message is sent from one time zone to another time zone I can store the UTC (GMT) time in my database and then have it displayed differently according to the user's time zone. But this can't be done when I only work with date.
If I say a task is due to the 21st of March. Should I consider that this date can be 20 or 22 in some other countries ? What are your advices on this problem ?
Let's say a user in New York sets a due date for a project as "anytime on Monday 26 January". That means "anytime from 0600 Monday 26 January to 0600 Tuesday 27 January" in Brussels and "anytime from 2000 Sunday 25 January to 2000 Monday 26 January" in L.A.
So completing the task at 2100 on Monday 26 is fine in Brussels and N.Y., but too late in L.A.
One possible work around is never just work with the date. If the time is not specified, either set it for 0000 hrs or 2400 hrs on the date specified in the timezone of the user.
The users may have to deal with strange due dates/times, but speaking as someone who used to work internationally, it kinda goes with the territory.
You won't be able to achieve what you are trying to do without storing the exact time. You simply don't have enough information.
When you don't have a time, assume that the time is the end of business in the main locale for the application, then translate that time as you would any other time. An alternative would be assuming end of the business day in local time and adjust that to UTC. Everyone using the application would need to understand whatever default time assumption you make when the time is not specified. Coordinating to the main office may be best in a large enterprise whereas coordinating to local time may be best in highly decentralized environments where the local context is equally important.
If you aren't storing the minutes and seconds you have to assume that the date being entered is the desired date and not to any adjustments for GMT. Just put it in the database as is. The people on the west coast will have to assume that the due date is the same regardless of where you are in the world. If you want to adjust for time zones, you'll have to collect more information, like hour, minutes, and seconds.
The easiest solution would be just to display as the same date for everyone. The deadline would then effectively be midnight in the latest timezone.
Otherwise, decide what the default time of the deadline should be in the timezone the task was created in, e.g. 21st March 17:00 EST or 22nd March 00:00 EST and display that in the local timezone. The timezone difference will then push it into the previous day or next day accordingly for the viewer.
SQL 2008 allows for a Date datatype that does not have any time value associated with it. That allows someone to say I need this done by this Date, but I don't care if it is +/- several hours. If the date selected is 1/1/2009 but it happens on 1/2/2009 at 2AM their time, they probably don't care.
When the user needs something done by a specific date and time, like close of business on 1/1/2009 then you need to store it in a DateTime as UTC and convert it to local time client-side.
This will take much of the complexity out of indicating when something is completed, it'll either be completed near a specific day or by a specific time.
If you have a single instance of a DB, I would store all dates in the datetime timestamp of your DB server. If you are timestamping rows, consider GetDate() in T-SQL or as default value of the timestamped date column. Then you have your single reference point for all times. Consider UTC format there.
Then, all clients accessing the date do their own conversion into "local time" , which can be interpreted by things like : user preferences, date time stamp on client computer, etc.
Without knowing more, it hard to say exactly what the resolution is.
Your solution depends on your application and requirements.
I'd first store UTC + offset in your data structures, so it's easy to display for any timezone.
Most likely if a task or meeting is due at 12pm on 21/March in London then it will occur at 2130 on 21/March in Adelaide (+0930), but that is an application requirement not any sinister timezone related standard.
If you want the ultimate in flexibility, add a flag that can make the even due simultaneously in every timezone or at the same time no matter where you are (staggered) and show the event accordingly.
You might want to store the date in a from that is timezone aware. This will help you in your calculations. SQL Server 2008 for instance supports a datetimeoffset that does precisely this. Alternatively if you're using SQL 2005 with a bit of effort you can write your own SQL CLR data type to support this.