Hi @sofie-bird, thanks for using Tasks, and for a very clear bug report.

FYI, I've tweaked the formatting of your report, so that the task lines can be copied and pasted in to markdown docs.

Can't reproduce the problem

I'm really puzzled by this, as I complete tasks like this, on their scheduled date all the time.

So I just tried the following steps:

1. Create a brand new vault
2. Install and Enable Tasks
3. Create a new note
4. Paste in this following line, with Shift held down

- [ ] test 🔁 every day ⏳ 2023-09-30

5. Switch to Reading mode
6. Toggle the task

Today's date is 2023-09-30

I get the correct result:

- [ ] test 🔁 every day ⏳ 2023-10-01
- [x] test 🔁 every day ⏳ 2023-09-30 ✅ 2023-09-30

Related issue reports

I've just re-read the following report...

• Recurring Task 'every day' gets stuck at the end of a month [the day before Australian clocks switch to daylight savings] #1200

It sounds like it might be similar to yours.

However, they were never able to reproduce it and we ended up closing it unresolved.

What is different about our setup?

To summarise:

• We have both done the same thing - set up a new vault.
• The issue reproduces for you, and not for me.

So, whilst it does look like there is an issue, if I cannot reproduce it, there is nothing I can do to fix it.

So all I think of is to try to figure out what, if anything, is different in your new vaults from mine.

1. What timezone are you in, if I may ask? I'm in:

British Summer Time
UK (GMT+1)

2. Check that the emoji have been read correctly.

The thing is, the recurring field is recognised, so I don't think this is the problem, as Tasks reads data from right to left, stopping when it reaches unrecognised text.

But what happens when you edit the original task? Can you please confirm that you see the same as this:

That screenshot confirms that both the emojis and their values were read correctly by Tasks.

Thanks for the prompt response.

I can confirm the task appears correctly (as in your screenshot) in the task editor -- I tested tasks created both manually and using the editor, both had the issue. It is correctly reading the emojis.

My timezone is AEST (UTC +10)
Possibly relevant as you're asking about timezones: tomorrow I switch into AEDT (UTC + 11) because we go into daylight savings. Might that explain why this suddenly turned up for me and can't be easily reproduced elsewhere? Perhaps I should re-test the issue tomorrow after my timezone has changed.

Edit - having read that original ticket, I note it's the same timezone, and the date of the issue (Oct 1 2022) was the day before we switched into daylight savings.

Edit - having read that original ticket, I note it's the same timezone, and the date of the issue (Oct 1 2022) was the day before we switched into daylight savings.

Good spot...

Since that last ticket was written, (I believe) I now understand how to set timezones in the Tasks automated tests.

So assuming that you confirm it's OK tomorrow, then when I have time, I can add some tests to confirm the problem.

I've no idea how much work it will be to fix it, so can't promise when a fix might be released...

I've updated the title of both issues to indicate what you've worked out, @sofie-bird ... thanks.

I tested this morning and I have found that:

• Tasks scheduled for today (Oct 1) behave as expected.
• Tasks scheduled for yesterday (day-before-DS-time) still have the 'same day' issue.
• Tasks scheduled for the day-before-DS-time ends (April 5, 2024) behave as expected.
• Tasks scheduled for the day-before-DS-time starts next year (Oct 5,2024) have the same-day issue.

So it seems like the current system time is not a factor, something about calculating the date across the timezone-change when entering daylight savings (eg 3am becomes 4am) is causing the issue.

No worries on the timeline of the fix, conveniently I have a plugin right here to set myself a reminder for why some tasks might play up October 5 next year :D

Hi Sophie,

That's brilliant - super helpful. Thanks for your understanding, too...

Confirm that I have the same problem here. As @sofie-bird said, the current system time doesn't appear to be important. In my case, I set both the due date and scheduled dates, and it is the due date that seems to be important.

Thanks Brian. Yes, for recurring tasks it’s the Due date that has the highest priority in deciding the next date.

I am facing a related issue in NZST (daylight time entered on 2024-09-29). Toggling the recurrence rule 🔁 every week on Sunday 📅 2024-09-22 incorrectly creates the next task instance with 🔁 every week on Sunday 📅 2024-09-28. The expected correct next task instance is 🔁 every week on Sunday 📅 2024-09-29.

@ishanarora Is it wrong just that one week, or every week?

@claremacrae it is correct for every week before. Toggling 🔁 every week on Sunday 📅 2024-09-28 creates another 🔁 every week on Sunday 📅 2024-09-28. After manually fixing it to 🔁 every week on Sunday 📅 2024-09-29 it starts recurring correctly. Following are the results of toggling a few tests:

- [x] task 1 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-20 ✅ 2024-10-15
- [ ] task 1 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-22

- [x] task 2 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-21 ✅ 2024-10-15
- [ ] task 2 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-22

- [x] task 3 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-22 ✅ 2024-10-15
- [ ] task 3 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-28

- [x] task 4 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-23 ✅ 2024-10-15
- [ ] task 4 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-28

- [x] task 5 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-24 ✅ 2024-10-15
- [ ] task 5 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-28

- [x] task 6 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-25 ✅ 2024-10-15
- [ ] task 6 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-28

- [x] task 7 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-26 ✅ 2024-10-15
- [ ] task 7 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-28

- [x] task 8 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-27 ✅ 2024-10-15
- [ ] task 8 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-28

- [x] task 9 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-28 ✅ 2024-10-15
- [ ] task 9 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-28

- [x] task 10 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-29 ✅ 2024-10-15
- [ ] task 10 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-10-06

- [x] task 11 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-09-30 ✅ 2024-10-15
- [ ] task 11 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-10-06

- [x] task 12 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-10-01 ✅ 2024-10-15
- [ ] test 12 🔁 every week on Sunday ➕ 2024-10-15 📅 2024-10-06

@ishanarora have your clocks just changed - or are they about to change?
I note the text [the day before Australian clocks switch to daylight savings] in the description...

Clocks changed on 2024-09-29 at 2am into 3am

I believe I have it pinned down. It appears moment().local(true) incorrectly assumes DST offset applies at every instant on the day DST is entered into. This is true only in geographies where DST takes effect at midnight. In truth the exact time DST is entered into varies across different timezones, for example at 2am in NZ, and at 01:00 UTC in the European Union. As a result moment().local(true) outputs incorrectly if the input time is within the first few hours of the date DST is entered into. Following are two demonstrations of the bug:

root@bc03ebef5105:~# TZ=Pacific/Auckland node
Welcome to Node.js v22.9.0.
Type ".help" for more information.
> var moment = require('moment');
undefined
> moment.utc('2024-09-29T00').local(true)
Moment<2024-09-28T23:00:00+12:00>
> moment.utc('2024-09-29T01').local(true)
Moment<2024-09-29T00:00:00+12:00>
> moment.utc('2024-09-29T02').local(true)
Moment<2024-09-29T01:00:00+12:00>
> moment.utc('2024-09-29T03').local(true)
Moment<2024-09-29T03:00:00+13:00>
> moment.utc('2024-09-29T04').local(true)
Moment<2024-09-29T04:00:00+13:00>
> 

root@bc03ebef5105:~# TZ=Europe/Athens node
Welcome to Node.js v22.9.0.
Type ".help" for more information.
> var moment = require('moment');
undefined
> moment.utc('2024-03-31T00').local(true)
Moment<2024-03-31T00:00:00+02:00>
> moment.utc('2024-03-31T01').local(true)
Moment<2024-03-31T00:00:00+02:00>
> moment.utc('2024-03-31T02').local(true)
Moment<2024-03-31T01:00:00+02:00>
> moment.utc('2024-03-31T03').local(true)
Moment<2024-03-31T02:00:00+02:00>
> moment.utc('2024-03-31T04').local(true)
Moment<2024-03-31T04:00:00+03:00>
> moment.utc('2024-03-31T05').local(true)
Moment<2024-03-31T05:00:00+03:00>
> moment.utc('2024-03-31T06').local(true)
Moment<2024-03-31T06:00:00+03:00>
> 

The bug is propagated to Recurrence.addTimezone because it uses moment().local(true). Submitting a PR to fix this shortly.