Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All Day Events #55

Open
jpincas opened this issue May 3, 2022 · 5 comments
Open

All Day Events #55

jpincas opened this issue May 3, 2022 · 5 comments

Comments

@jpincas
Copy link

jpincas commented May 3, 2022

Thanks so much for this package - you've saved me hours!

Just wanted to report on my findings while trying to work out how to output an 'all day event'. 99% this is down to me not knowing how to use iCal spec/this package, but just wanted to make some notes/ask a question.

From inspecting other feeds that were showing all day events correctly, it looked like the structure needed to be:

DTSTART;VALUE=DATE:20201101

To get that output I had to bypass the helper functions, format the date manually with a copy of your 'icalDateFormatLocal' (otherwise the Z at the end caused the event not to display) and manually specify the DATE value.

event.SetProperty(ics.ComponentPropertyDtStart, t.Start.UTC().Format(icalDateFormatLocal), ics.WithValue("DATE"))

I imagine that I'm missing a much easier way to do this, but couldn't find it to save my life.

@arran4
Copy link
Owner

arran4 commented May 3, 2022

No worries. Thanks! Glad it saved you time.

We do have some helper functions for Event DT Start at

func (event *VEvent) SetStartAt(t time.Time, props ...PropertyParameter) {

We had some discussion around it here: #47

Does that work for you?

The library is really just a serializer / deserializer and probably needs another layer to make it more usable. Other people have asked this of me. Sadly I didn't / don't have time to do this right now.

@miroslavhajek
Copy link

@jpincas Hi, I have same problem. This lib doesn't works with Apple Calendar when event is all day type.

My workaround:

const (
	dateFormatUtc = "20060102"

	propertyDtStart ical.Property = "DTSTART;VALUE=DATE"
	propertyDtEnd   ical.Property = "DTEND;VALUE=DATE"

	componentPropertyDtStart = ical.ComponentProperty(propertyDtStart)
	componentPropertyDtEnd   = ical.ComponentProperty(propertyDtEnd)
)

cal := ical.NewCalendar()
event := cal.AddEvent("1")
event.SetProperty(componentPropertyDtStart, time.Now().UTC().Format(dateFormatUtc))
event.SetProperty(componentPropertyDtEnd, ...)

@arran4
Copy link
Owner

arran4 commented Oct 8, 2022

What does a native Apple Calendar "all day" event look like?

@kevinmorio
Copy link

kevinmorio commented Dec 19, 2022

Hi, let me chime in as the same problem occurred to me as well.

First, to answer your question @arran4, an all day event from Apple Calendar looks like this

BEGIN:VEVENT
DTEND;VALUE=DATE:20230222
UID:EDF57D2A-FA37-4FFD-9076-921572E37CAB
SUMMARY:All Day Event
DTSTART;VALUE=DATE:20230221
DTSTAMP:20221219T195041Z
END:VEVENT

For an all day event, a value type of DATE is used both for the DTSTART and DTEND properties with an offset of one day for DTEND. From my testing, Android and Nextcloud use the same format. Importing works as expected.

Coming back to the library, using the corresponding helper functions SetAllDayStartAt and SetAllDayEndAt produces an event like this

BEGIN:VEVENT
DTSTART:20221231Z
DTEND:20221231Z
SUMMARY:All Day Event
DTSTAMP:20221219T200805Z
END:VEVENT

However, these values for DTSTART and DTEND are invalid for the value type DATE-TIME according to iCalendar spec: 4.3.5 Date-Time as they don't contain a time but the UTC Z.

As noticed by @jpincas and myself, it also seems to work by removing the UTC Z at the end. However, this doesn't seem to be in the specification.

I propose changing the helper functions to

const icalDateFormat = "20060102"

func (event *VEvent) SetAllDayStartAt(t time.Time, props ...PropertyParameter) {
	event.SetProperty(ComponentPropertyDtStart, t.UTC().Format(icalDateFormat), WithValue(string(ValueDataTypeDate)))
}

func (event *VEvent) SetAllDayEndAt(t time.Time, props ...PropertyParameter) {
	event.SetProperty(ComponentPropertyDtEnd, t.UTC().Format(icalDateFormat), WithValue(string(ValueDataTypeDate)))

I'm not sure if we should also add the one day offset in the helper method.

dnwe added a commit to dnwe/golang-ical that referenced this issue Apr 5, 2023
For a date-only event (i.e., an event that lasts for the full day) the
iCalendar specification indicates that the value for DTSTART / DTEND
should be a DATE

https://icalendar.org/iCalendar-RFC-5545/3-6-1-event-component.html

> The "VEVENT" is also the calendar component used to specify an
> anniversary or daily reminder within a calendar. These events have a
> DATE value type for the "DTSTART" property instead of the default value
> type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it MUST be
> specified as a DATE value also

The DATE format
(https://icalendar.org/iCalendar-RFC-5545/3-3-4-date.html) should omit
both time and zone/location elements and additionally notes that "The
"TZID" property parameter MUST NOT be applied to DATE properties"

As per the specification, this PR also adds an explicit "VALUE=DATE"
parameter when the AllDay helpers were called, to indicate that the
property's default value type has been overridden and the VEVENT is
intended to be an all-day event
https://icalendar.org/iCalendar-RFC-5545/3-2-20-value-data-types.html

Finally the SetDuration call has been updated to preserve the "AllDay"
characteristics if the existing start or end has been specified in DATE
format, which is also a requirement of the spec.

Contributes-to: arran4#55
dnwe added a commit to dnwe/golang-ical that referenced this issue Apr 5, 2023
For a date-only event (i.e., an event that lasts for the full day) the
iCalendar specification indicates that the value for DTSTART / DTEND
should be a DATE

https://icalendar.org/iCalendar-RFC-5545/3-6-1-event-component.html

> The "VEVENT" is also the calendar component used to specify an
> anniversary or daily reminder within a calendar. These events have a
> DATE value type for the "DTSTART" property instead of the default value
> type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it MUST be
> specified as a DATE value also

The DATE format
(https://icalendar.org/iCalendar-RFC-5545/3-3-4-date.html) should omit
both time and zone/location elements and additionally notes that "The
"TZID" property parameter MUST NOT be applied to DATE properties"

As per the specification, this PR also adds an explicit "VALUE=DATE"
parameter when the AllDay helpers were called, to indicate that the
property's default value type has been overridden and the VEVENT is
intended to be an all-day event
https://icalendar.org/iCalendar-RFC-5545/3-2-20-value-data-types.html

Finally the SetDuration call has been updated to preserve the "AllDay"
characteristics if the existing start or end has been specified in DATE
format, which is also a requirement of the spec.

Contributes-to: arran4#55
dnwe added a commit to dnwe/golang-ical that referenced this issue Apr 28, 2023
For a date-only event (i.e., an event that lasts for the full day) the
iCalendar specification indicates that the value for DTSTART / DTEND
should be a DATE

https://icalendar.org/iCalendar-RFC-5545/3-6-1-event-component.html

> The "VEVENT" is also the calendar component used to specify an
> anniversary or daily reminder within a calendar. These events have a
> DATE value type for the "DTSTART" property instead of the default value
> type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it MUST be
> specified as a DATE value also

The DATE format
(https://icalendar.org/iCalendar-RFC-5545/3-3-4-date.html) should omit
both time and zone/location elements and additionally notes that "The
"TZID" property parameter MUST NOT be applied to DATE properties"

As per the specification, this PR also adds an explicit "VALUE=DATE"
parameter when the AllDay helpers were called, to indicate that the
property's default value type has been overridden and the VEVENT is
intended to be an all-day event
https://icalendar.org/iCalendar-RFC-5545/3-2-20-value-data-types.html

Finally the SetDuration call has been updated to preserve the "AllDay"
characteristics if the existing start or end has been specified in DATE
format, which is also a requirement of the spec.

Contributes-to: arran4#55
@arran4
Copy link
Owner

arran4 commented Oct 16, 2024

Hi @jpincas and @kevinmorio @miroslavhajek

I believe that some issues with all day events has been addressed in a previous PR (you can see them reference this) can someone give me an idea of the current issues with the implementation. Having done some work around it recently in a couple PRs but what comes to mind is: #110 . It needs some work IMHO however I can't really do that without knowing the issues.

I have some time today and tomorrow to work on it and hopefully next weekend as well. Let me know.

I will close this in November if no responses.

@arran4 arran4 self-assigned this Oct 16, 2024
ManoloTonto1 pushed a commit to ManoloTonto1/golang-ical that referenced this issue Oct 21, 2024
* Add leaks and vunerability checks

* Requires secrets now

* Renamed interface as it's useful own it's own. Made it public. Added a comment

* fix: omit zone in "AllDay" event helpers

For a date-only event (i.e., an event that lasts for the full day) the
iCalendar specification indicates that the value for DTSTART / DTEND
should be a DATE

https://icalendar.org/iCalendar-RFC-5545/3-6-1-event-component.html

> The "VEVENT" is also the calendar component used to specify an
> anniversary or daily reminder within a calendar. These events have a
> DATE value type for the "DTSTART" property instead of the default value
> type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it MUST be
> specified as a DATE value also

The DATE format
(https://icalendar.org/iCalendar-RFC-5545/3-3-4-date.html) should omit
both time and zone/location elements and additionally notes that "The
"TZID" property parameter MUST NOT be applied to DATE properties"

As per the specification, this PR also adds an explicit "VALUE=DATE"
parameter when the AllDay helpers were called, to indicate that the
property's default value type has been overridden and the VEVENT is
intended to be an all-day event
https://icalendar.org/iCalendar-RFC-5545/3-2-20-value-data-types.html

Finally the SetDuration call has been updated to preserve the "AllDay"
characteristics if the existing start or end has been specified in DATE
format, which is also a requirement of the spec.

Contributes-to: arran4#55

* calendar parsing url support

* usage example, README

* added functionnal option pattern for url parsing

* Should be able to distinguish unset from invalid time properties

* Improve error for property not found

Co-authored-by: Arran Ubels <[email protected]>

* Remove deprecated ioutil

* Move targeted Go version to 1.20

And test the target forever

* Add method to remove property

Fixes arran4#95

* Merged

* New tool

* Reintegration of arran4#67

* Resynced and moved some functions around arran4#78

* Test fixed.

* Create bug.md

* Create other.md

* Create default.md

* Rename default.md to pull_request_template.md

* Minor update

* refactor: remove unnecessary named return values, harmonizing code base

* refactor: rename var to reflect what it is

These functions take optional variadic PropertyParam arguments, in ical
speak they are not properties, but parameters for a property.

* refactor: use ReplaceAll

* refactor: prefer switch for readability

* refactor: use consistent receiver names

* refactor: rename unused arg as '_'

* Tests added.

* Some larger upgrades.

* Fix

* Some multiple-ness.

* Duplication issue fixed.

* Merged

* Merge remote-tracking branch 'origin/master' into issue97

* origin/master:
  Duplication issue fixed.
  Some multiple-ness.
  Test fixed.
  Resynced and moved some functions around arran4#78
  added functionnal option pattern for url parsing
  usage example, README
  calendar parsing url support

# Conflicts:
#	calendar.go
#	calendar_test.go
#	components.go

---------

Co-authored-by: Dominic Evans <[email protected]>
Co-authored-by: tradulescu <[email protected]>
Co-authored-by: Bracken Dawson <[email protected]>
Co-authored-by: Daniel Lublin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants