Calendar abstraction

[leevigraham]

Our apps need custom calendars for reporting and grouping. Costimator had the following calendars:

• Fiscal Gregorian
• Fiscal 445
• Gregorian
• Gregorian 445

445 calendars can also be 544 and 454.

Interesting links:

• http://en.wikipedia.org/wiki/4%E2%80%934%E2%80%935_calendar
• http://yohan.giarel.li/CalendR/index.html
• https://gist.github.com/trq/7814691

[ghost]

I think the costimator solution was pretty spot on, and solves 90% of date cases. The only thing we haven't addressed or come across yet is the idea of recurring events, and the ability to edit certain dates within a series. I think if we can get this figured out, I think we'd pretty much there?

Thinking about it, I have a series, which is a repeated 'event'. Depending on the case, this event could be the same entity (User:birthday), or each on a separate, auto-generated one (VehicleService:date).

Typically, you can edit an occurrence within a series in two ways, all after this occurrence OR just this occurrence. My quick thoughts on implementing this:

All after this occurrence:

• Set the endDate of the original series to the day prior (or suitably determined date)
• Create a new series from date of the edited occurrence to the endDate of the original
• Set the parentSeries property of the new series to the parentSeries of the original series, or it's id if it doesn't have a parent. (Much like the originalRecipe solution in costimator)

Just this occurrence:

• Create a new event for the date of this occurrence, leaving the series as is
• Set a singleOccurrence flag that this is a single occurrence edit.
• Set the parentSeries to that of the series this occurrence belongs to.

To get a series we could then

SELECT *
FROM seriesEvents
WHERE 
-- Make sure we include series that start and end within our period
(startDate < end of period OR endDate > start of period) AND
parentSeries = x AND 
singleOccurrence = 0

From this build out our series without single edits then

SELECT *
FROM seriesEvents
-- Make sure we include events that start and end within our period
(startDate < end of period OR endDate > start of period) AND
WHERE
parentSeries = x AND 
singleOccurrence = 1

And overwrite the events in the series where there are single edits.

[ghost]

Just realised this doesn't take into consideration deleting events from a series. In this case it might act the same way as All after this occurrence where we create a new series but start it at the date of the NEXT occurrence.

Also, all this seems like a pretty massive amount of processing. Could it be that any edits here effect the entities directly (there is no way to edit these dates otherwise on the constituent entities) and once you make edits everything gets ead'ed (BREAD'ed?) so all future queries are correct? i.e. VehicleService are created for those dates. To do this we'd require a hard limit on endDate (depending on the app, ClubEvo perhaps 4 years, cositmator perhaps 1 year) as we couldn't be creating VehicleService entities for say 2038.