- 🇳🇱Netherlands johnv
It seems the recurrence rule is not needed for the OfficeHours FieldFormattes, but only for Views integration with Calendar or FullCalendar, where each 'timeslot' can be added to a calendar.
at the moment, the office_hours cannot be displayed in a calendar view via
Calendar →
,
FullCalendar →
or
FullCalendar View →
.
Implementing this in the current design is not feasible.
Therefore, let's investigate if implementing the ISO 8601 format would solve the puzzle.
See the child issues, and
✨
[Season Meta] Add "Seasonal Hours / Duration" feature
Fixed
From #2384453-10: Port office_hours to Drupal 8 → by @darrick:
I'm curious if the storage for starthours and endhours could be of type datetime_iso8601 instead of int. That way you could reuse more of the formatters for datetime. Possibly could shove the day into them, too.
I mainly work on a project for creating reservations ( https://www.drupal.org/project/merci → ) and have a sub-module for open hours. I have validation functions to check if the time reserved is within the open hours so having the open hours hold a date object helps a bit. I can write wrappers nonetheless.
The following recurring date formats must be evaluated:
- ISO 8601
- iCalendar Recurrence Rule (RRULE), which is used by other contrib fields like
Recurring Dates Field →
and
Smart Date →
The ISO 8601 format contains the following (relevant) parts, using the 'extended format', not the 'basic format':
Dates
- calendar date: YYYY-MM-DD
- calendar date in a certain month: YYYY-MM (basic format is not supported)
- week date: YYYY-Www-D, where W is the Week number and D is the weekday(1=sunday - 7=saturday). Week number W is arbitrary in our use case, but can be specified for an Exception day.
-
Times
- time: T[hh]:[mm]
- midnight may be referred to as "00:00:00", corresponding to the instant at the beginning of a calendar day; or "24:00:00", corresponding to the instant at the end of a calendar day.
- Time zone: local time, since time zones are not supported (yet) in this module (are represented as local time (with the location unspecified), as UTC: Z, or as an offset from UTC: ±hh:mm)
Combined date and time representations: T, for example, "2022-04-05T14:30" (both date and time must be in the same format, so extended format). The date expression must use a complete representation (so perhaps YYYY-MM is not permitted)
- Duration vs. Time intervals: In the current design, the module uses interval: from 09:00 until 18:00.
Time intervals
We can stick to the current design with time intervals:
- normal time with calendar date: 09:00-18:30, such as "2022-03-01T09:00/18:30"
- normal time with week date: Monday 09:00-18:30, such as "2022-W01-1T09:00/18:30"
- night club time: 23:00-06:00, such as "2022-03-01T23:00/06:30" (but perhaps ISO requires "2022-03-01T23:00/2022-03-02T06:00", which we do not like, since having 2 dates is confusing)
- all-day open: 00:00-24:00, such as "2022-03-01T00:00/24:00"
- all-day closed: 00:00-00:00, such as "2022-03-01T00:00/00:00" (or "2022-03-01", implying no from/to times = 00:00)
Duration
Or we choose a new design with durations (using suffix PxHyM):
- normal time: 09:00-18:30, such as "2022-03-01T09:00P9H30M"
- night club time: 23:00-06:00, such as "2022-03-01P7H00M" (having no ISO problem)
- all-day open: 00:00-24:00, such as "2022-03-01T00:00P24H00M"
- all-day closed: 00:00-00:00, such as "2022-03-01T00:00P00H00M"
Recurring dates/Repeating intervals (or 'Recurring time interval')
Repeating intervals are formed by adding "R[n]/" to the beginning of an interval expression, where R is used as the letter itself and [n] is replaced by the number of repetitions. Leaving out the value for [n] or specifying a value of -1, means an unbounded number of repetitions. A value of 0 for [n] means the interval is not repeated.
For example, to close for 1week for holidays, add "R7/" to the date expression:
- all week closed: "R7/2022-03-01P00H00M"
- open each Monday 09:00-18:30: "R-1/2022-W01-1T09:00/18:30"
- exception Monday 09:00-11:30: "R0/2022-W08-1T09:00/11:30"
- all week closed: "R7/2022-03-01P00H00M"
Standardised extensions
The iCalendar "DATE-TIME" value type is used to identify values that contain a precise calendar date and time of day. The format is based on the [ISO.8601.2004] complete representation, basic format for a calendar date and time of day. The text format is a concatenation of the "date", followed by the LATIN CAPITAL LETTER T character, the time designator, followed by the "time" format. (so, 20220101T090000 vs. 2022-01-01T09:00:00)
...
Example for each Monday 09:00-18:30 :
DTSTART;20220101T090000
RRULE:FREQ=WEEKLY;UNTIL=99991231T183000Z
or (with WKST = weekstart = Sunday):
DTSTART;20220101T090000
RRULE:FREQ=WEEKLY;WKST=SU;BYDAY=MO
- Duration: is based on the [ISO.8601.2004] complete representation basic format with designators for the duration of time.
- Recurrence: https://icalendar.org/iCalendar-RFC-5545/3-3-10-recurrence-rule.html
- evaluate above examples in ISO 8601
- evaluate above examples in ICalendar RRULE
- check with core Date module and contrib date modules
- check with contrib modules
Calendar →
,
FullCalendar →
,
FullCalendar View →
--
✨
Date Recur 3.x and Fullcalendar 5.x
Closed: outdated
- check the statement in
Calendar module →
, 'core Date does not support recurring dates (aka repeating intervals)'
- check compatibility with mentioned Calendar modules (where 1 office day record may have several recurring dates)
The 'Week' widget does not change for 'normal' usage.
The 'Week with exceptions' widget will not or slightly change exception days (X-mas 2022).
The 'Week with exceptions' widget will be extended for 'seasons' (opening days in july-august).
@todo: design the widget here.
The field data record will have a new subfield/column 'value' holding the above mentioned date expressions.
Eventually this will replace/deprecate the existing subfields.
The new subfield/column will hopefully have direct integration with Date and Calendar modules.
The communication between data record and Widget + Formatter needs to be implemented from scratch.
Active
1.0
Integrating Views
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
It seems the recurrence rule is not needed for the OfficeHours FieldFormattes, but only for Views integration with Calendar or FullCalendar, where each 'timeslot' can be added to a calendar.