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

fix compatibilty with tz_info #22

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

phoet
Copy link

@phoet phoet commented Feb 19, 2021

While upgrading to to Rails 6.1 my tests using ri-cal failed. Turns out the upgrade to tz-info 2.0.4 removes / renames a couple of methods.

Does not look like this is still actively maintained, but it might be helpful to others.

@phoet
Copy link
Author

phoet commented Feb 19, 2021

@rubyredrick I had to make some adjustments to allow this to run with a current ruby setup.

@@ -0,0 +1,47 @@
PATH

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest to add the Gemfile.lock to the .gitignore file.

def period_local_end(period)
(period.local_end || DateTime.parse("99990101T000000")).strftime("%Y%m%dT%H%M%S")
(period.local_ends_at&.to_datetime || DateTime.parse("99990101T000000")).strftime("%Y%m%dT%H%M%S")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(period.local_ends_at&.to_datetime || DateTime.parse("99990101T000000")).strftime("%Y%m%dT%H%M%S")
(period.local_ends_at && period.local_ends_at.to_datetime || DateTime.parse("99990101T000000")).strftime("%Y%m%dT%H%M%S")

As &. is a Ruby 2.6 feature and this gem is really old and most likely used in old services.

If you insist on using it, you should add spec.required_ruby_version = ">= 2.6.0" to the .gemspec and the version should be raised at least by a minor level.

# This assumes a 1 hour shift which is why we use the previous period local end when
# possible
def period_local_start(period)
shift = daylight? ? Rational(-1, 24) : Rational(1, 24)
((period.local_start || DateTime.parse("16010101T000000")) + shift).strftime("%Y%m%dT%H%M%S")
((period.local_starts_at&.to_datetime || DateTime.parse("16010101T000000")) + shift).strftime("%Y%m%dT%H%M%S")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above

@langalex
Copy link

I'm having the same problem. It would be ideal if we could release a new gem (ri_cal_new?). I'd be willing to help. @phoet could you give me access to your fork so I can fix the issues brought up by @mediafinger?

@langalex
Copy link

then again, there is https://github.com/icalendar/icalendar, which seems to be maintained.

@phoet
Copy link
Author

phoet commented Dec 26, 2021

@langalex did you switch to icalendar? i don't recall why i used ri_cal in the first place...

@langalex
Copy link

@phoet i did. works like a charm.

@phoet
Copy link
Author

phoet commented Dec 26, 2021

👍 will do the same

@phoet
Copy link
Author

phoet commented Dec 26, 2021

merry christmas everyone 🎄

salzig added a commit to rughh/on_ruby that referenced this pull request Aug 15, 2024
based upon rubyredrick/ri_cal#22 (comment) i assume phoet intended to replace the quite outdated ri_cal with icalendar a while ago.
so doing it now :)
JoschkaSchulz pushed a commit to rughh/on_ruby that referenced this pull request Sep 16, 2024
based upon rubyredrick/ri_cal#22 (comment) i assume phoet intended to replace the quite outdated ri_cal with icalendar a while ago.
so doing it now :)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants