[TW-13] Recurring tasks and daylight saving time

[taskwarrior]

Dirk Deimeke on 2011-02-14T03:25:32Z says:

It seems that recurring tasks are done by "simple" arithmetics. That does not work well, since you lose or gain an hour due to daylight saving times.

Example:

Some time ago (20100927) I created a weekly recurring task due on Sunday, 23:59 hrs. After daylight saving time changes, it got a due date of Sunday, 22:59 hrs (should be 23:59 hrs, regardless of any dst changes).

This is only annoying and not a real problem. I have no idea how to implement that apart from saving "sunday, 23:59" anywhere.

[taskwarrior]

Migrated metadata:

Created: 2011-02-14T03:25:32Z
Modified: 2015-10-19T04:46:02Z

[taskwarrior]

Federico Hernandez on 2011-02-14T06:39:45Z says:

time and date fun... Thx Dirk for reporting this.

[taskwarrior]

Federico Hernandez on 2011-06-13T21:03:29Z says:

needs to wait for kronisk as well as it needs some more thinking

[taskwarrior]

Paul Beckingham on 2013-02-10T22:29:24Z says:

Still waiting for kronisk to develop a policy for handling this.

[taskwarrior]

atomicules on 2014-10-27T22:21:36Z says:

I recently got bit by this as British Summer Time just ended in the UK and I use a lot of recurring tasks.

In my case the tasks should have been on a date with a time of 00:00:00. After daylight saving changed the times of the tasks were all 23:00:00 which had shifted them back a day.

I put together a quick shell script to go through all my tasks, look for a Due date containing 23:00:00 and shift them all to the following day. I'm attaching it only as a starting point for others who have suffered the same issue. Certainly don't just run it as it is!

If the project admins aren't happy with me posting this here (it's not an official script, etc) please feel free to remove.

[taskwarrior]

atomicules on 2014-11-05T13:02:49Z says:

Further to the half-a-hacky-fix I attached with my last comment I've realised that only fixes child tasks of status:pending that have already been created from the parent recurring tasks. This means that when new tasks are automatically created from the parents they'll also suffer the same problem.

So... probably worth doing something like task task status:recurring ids modify due:'due + 1hour' (that works in 2.4.0) to shift the parent tasks forward an hour. Ideally limit that to only the parents that were created within DST, but I doubt it'd be a huge issue to advance all.

[taskwarrior]

atomicules on 2014-11-12T13:59:49Z says:

Further to my previous comment I realised that fix wouldn't work as at some point I'd end up with tasks on the same day, but with different due times. For my use of Taskwarrior this would be no good: I use sorting on due date to group tasks by the same day only, for sorting within the day I use a UDA.

Therefore I decided to look into recur.cpp and see if I could come up with a fix there. I have come up with something that works for me, but, because it has edge cases and because I can't think of any way to write a test that will handle a DST change for whoever is running it, I have uploaded the [patch as a Gist|https://gist.github.com/atomicules/a250cc5bb359336407bd] rather than include it here as I can't see it being merged in.

[pbeckingham]

TW-13_taskdstfix.sh.txt

[madduck]

Is there any reason why taskwarrior doesn't just use proper timezones? Or does it, and is that the problem? Then why aren't those shown in the task details? There is a LOCAL timezone AFAIK which basically serves to ignore daylight savings…

[vl-01]

I've been bitten by this as well. I've got some ideas and am willing to attempt a patch but as per the DEVELOPERS.md I'd like to discuss it beforehand. I'm thinking of using either Howard Hinnant's date library or stdlibc++20's calendar and timezone modules as a base, since they already handle a lot of the thorny logic, but this involves adding a dependency on one hand or setting a later C++ standard on the other.
Unless it is preferred to add timezone functionality to the Datetime module in libshared?

[vl-01]

For consideration, this is what I would do:

1. Replace datetime type instances with a zoned_time from stlibc++20
2. Parse datetimes in the timezone given, or local time if none given
3. When creating tasks, or recurring tasks, or modifying dates that cross a time-zone transition boundary (EST to EDT, for example), resolve it either by policy (settable in taskrc) or by interactive user prompt. For example, if I have a class scheduled at every Wednesday at 18:00, my expectation is that the recurring task is scheduled for 18:00 even if the parent task was created in EDT and we have since transitioned to EST (current behavior would schedule the recurring task at 19:00 after the boundary is crossed).
4. I'd also like to address pure local datetimes possibly by using a variant<zoned_time, local_time> instead of just zoned_time. This is for scheduling personal tasks that depend only on your immediate local time, and should keep the same wall clock regardless of where one travels.

[mibu138]

Just wanted to chime in on this that I also have been burned by this. I was really hoping I'd be able to avoid the need for a separate calendar app and just use tw for everything. And it almost worked. I tried running some of the bandaid scripts people have linked to, but unfortunately it doesn't seem like there is a trivial fix that I could just reliably set to run on every DST change. And there are probably more issues I've yet to hit that stem from the fundamental problem that tw has, what sounds like, a simplistic notion of time. That is not meant to be a knock, btw. I love tw for what it does well. And I get that time is a fairly tricky problem to get right robustly. Which is why I am not able to offer any suggestions on how to fix this problem. I only hope this feedback is will be taken in good faith and might lead to future imrpovements in this area.

[insanerwayner]

Just thought I would share the script i've been using the last few years to solve this. This also corrects any wait dates you may have.

#!/bin/sh
for task in $(task +CHILD _ids)
do
        #Get only the Due and Wait date line and not modification lines
        wrongduedate=$(task "$task" info | grep -E '(^Due.*23:00:00$|^Due.*01:00:00$)' | awk '{print $2, $3}')
        wrongwaitdate=$(task "$task" info | grep -E '(^Waiting until.*23:00:00$|^Waiting until.*01:00:00$)' | awk '{print $3, $4}')
        #Only modify if task due contains 23:00:00 or 01:00:00
        if [ -n "$wrongduedate" ]; then 
                case "$wrongduedate" in
                    *01:00:00 )
                                echo "Correcting Due Date for task $task: Back One Hour"
                                task "$task" rc.confirmation:no rc.recurrence.confirmation:yes modify due:due-1h
                                ;;

                    *23:00:00 )
                                echo "Correcting Due Date for task $task: Up One Hour"
                                task "$task" rc.confirmation:no rc.recurrence.confirmation:yes modify due:due+1h
                                ;;
                esac
        fi
        if [ -n "$wrongwaitdate" ]; then 
                case "$wrongwaitdate" in
                    *01:00:00 )
                                echo "Correcting Wait Date for task $task: Back One Hour"
                                task "$task" rc.confirmation:no rc.recurrence.confirmation:yes modify wait:wait-1h
                                ;;

                    *23:00:00 )
                                echo "Correcting Wait Date for task $task: Up One Hour"
                                task "$task" rc.confirmation:no rc.recurrence.confirmation:yes modify wait:wait+1h
                                ;;
                esac
        fi
done