-
-
Notifications
You must be signed in to change notification settings - Fork 239
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
Recurring until parser seems to subtract one day when parsing #1818
Comments
Welp, it's actually a bug in const { RRule } = require('rrule');
let rule = RRule.fromText('every 5 weeks on Monday, Friday until January 31, 2013')
console.log(rule.toText());
// "every 5 weeks on Monday, Friday until January 30, 2013" |
Found it: jkbrzt/rrule#486 The problem apperas to be, that the date is parsed in the local timezone and then converted into UTC wich somehow misses a day. A solution seems to be to add "UTC" to the day, but that won't be output when converted to text again... EDIT: Just noticed, that the mentioned bug report was made by a maintainer... whoopsies, embarrassing. |
Ok, one horrible workaround that could be applied by Tasks (until jkbrzt/rrule#529 or similar is merged) is this: Whenever the keyword "until" is present in an rrule, just append " UTC". Kinda stupid but should do the trick. If you have better ideas, I'd love to help, but as it stands now, the until clause is unusable for anyone in a timezone with an offset of >0. |
Thank you for logging this. I do believe you have re-discovered the source of point 2 in this section of the Tasks docs: https://obsidian-tasks-group.github.io/obsidian-tasks/getting-started/recurring-tasks/#known-issues
I've added a link, there, to this issue. The change will be published next time a release is done.
I would certainly accept a PR for this, if it was well covered with unit tests, and had been thoroughly tested manually in a variety of time zones. To get started developing tasks, we now have the Contributing Guide. If you're interested, I can show you how I figured out to set the timezone when running jest. (I will add it to the Contributing guide at some point, but that's a long way from the top of a very long list.) |
PS This issue and any analysis of it predates my involvement with this project, hence my not knowing the background - so what you have captured here is very helpful indeed. Thank you. |
Ok, I'll look into it at some point.
First I have to figure out how jest works at all 😅 |
I’d be happy to pair with you to help set up your dev environment and talk you through the tests. My email is in my profile here if you would to set a session up. |
Hi @TobTobXX,
If you ever do feel like having a look at this, the following may help...
|
It also occurred to me that if the bug is totally consistent, then a workaround would be:
|
how about this as a way to deal with this completely in tasks. find the "until" in the string and remember that string. when the new item is created replace the "until" part of the string with the saved original string. |
Thanks for the suggestion @pcause! |
Please check that this issue hasn't been reported before.
Expected Behavior
I have this task:
And I check it, then I should get this:
Current behaviour
I have this task:
And I check it and get this:
Note that the "until date" has changed.
It's quite funny, because when you open the task in the editor, you can see 2 different dates, because each parsing pass subtracts one day. In the above case it would be "March 29, 2023" in the Markdown file, "March 28, 2023" in the parsed text field in the "Create or edit Task" dialog and just below the (again parsed) text: "March 27, 2023".
Also, as a side note, ISO date format doesn't work there, which is a shame.
Steps to reproduce
see above
Which Operating Systems are you using?
Obsidian Version
v1.1.16
Tasks Plugin Version
2.0.1
Checks
Possible solution
It's quite possible that this is a bug of the NL parser library used?
If you give me a couple of days, I'll dig into the source myself and see if I can come up with a fix.
The text was updated successfully, but these errors were encountered: