allDay property for Events

[danbri]

This is a proposal from Google, based on experience building products that use Schema.org Event descriptions.

Currently it is hard to determine if an Event is considered "all day". Heuristics like start date and end dates being the same day are complicated if an event continues for more than one day, but each day is "all day". It would be good to have a more explicit handling of this concept.

Suggestion:

:allDay a rdf:Property ; rdfs:label "allDay" ; schema:domainIncludes schema:Event ; schema:rangeIncludes schema:Boolean ; rdfs:comment "Whether this is an 'all day' type of event that doesn't specify hour/minutes granularity for start time or duration." .

Apparently this has been discussed over in the icalendar standard:

A proposal there from 2014:

I came up with this too after looking into the RFC and diffing the output of a thunderbird-lightning export. Though I would consider it a work around. Even though the RFC does not seem to include an explicit "allday" boolean most calendar clients soft of emulate it by giving you a checkbox that says "all day". Would you perhaps consider something like this checkbox by adding something like this?

event.allday = true

Apparently this was added to the icalendar Wiki, which I haven't yet found.

Looking at https://datatracker.ietf.org/doc/rfc5545/ I don't see a treatment of "all day".

[smrgeoinfo]

problem is what is 'all day'-- is that a 9-5 local time business day, a noon-midnight day (at the carnival), or 24 hour day? What about events that start on day one a 5 pm and end on day 4 at noon?
Partly has to do with perspective. On my calendar, when I see an 'all day' event, I know what that means to me. But if its in a posting about some other event (festival, workshop, store hours) I'd need more information to schedule my time around the event. using DateTime instead of just Date for start and end of event provides one level of granularity. Next level would be to provide daily operational hours (open, close; as xsd:Time with time zone). Next level is operational hours for each day of event. The sweet spot depends on the use cases that need to be supported.

[wuda-io]

Why not use full dates as startDate and endDate e.g. startDate: "2022-06-22", endDate: "2022-06-22" would describe a fullday event.

or startDate: "2022-06-22", endDate: "2022-06-23" startDate: "2022-06-22 00:00:00", endDate: "2022-06-23 00:00:00"

[danbri]

If a lunch event happened on that day, and we didn’t have (or choose to publish) exact details, then it could also be described this way

On Wed, 22 Jun 2022 at 08:47, Daniel Wurzer @.***> wrote:

Why not use full dates as startDate and endDate e.g. startDate: "2022-06-22", endDate: "2022-06-22" would describe a fullday event.

or startDate: "2022-06-22", endDate: "2022-06-23" startDate: "2022-06-22 00:00:00", endDate: "2022-06-23 00:00:00"

— Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/3101#issuecomment-1162767098, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGNH33OH7LFWELKHYWLVQLAK3ANCNFSM5UJJE34A . You are receiving this because you authored the thread.Message ID: @.***>

[chrisspradling1980]

This is an excellent point. Don't forget about the UTC being able to go forward in time and backwards through paradoxes matricide.

On Wed, Jun 22, 2022, 3:28 AM Dan Brickley @.***> wrote:

If a lunch event happened on that day, and we didn’t have (or choose to publish) exact details, then it could also be described this way

On Wed, 22 Jun 2022 at 08:47, Daniel Wurzer @.***> wrote:

Why not use full dates as startDate and endDate e.g. startDate: "2022-06-22", endDate: "2022-06-22" would describe a fullday event.

or startDate: "2022-06-22", endDate: "2022-06-23" startDate: "2022-06-22 00:00:00", endDate: "2022-06-23 00:00:00"

— Reply to this email directly, view it on GitHub < https://github.com/schemaorg/schemaorg/issues/3101#issuecomment-1162767098 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AABJSGNH33OH7LFWELKHYWLVQLAK3ANCNFSM5UJJE34A

. You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/3101#issuecomment-1162806644, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFVNUQISZXTQ6BL5LGWZNDVQLFDBANCNFSM5UJJE34A . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[github-actions[bot]]

This issue is being nudged due to inactivity.