Bug report: ToDos 10/20 years out wrap around to the past

I have an appointment that repeats every 10 years ("renew passport"). I completed it, so I check it off. Next time I refresh, I still see it, even though I have "hide future tasks" filter turned on. Why? Because the date has wrapped around to Dec 31, 1969. (I might have checked it off twice due to this, so it might not have wrapped until 20 yrs in the future.) Perhaps you're using a 32-bit Unix date representation. We're not all that far from 2038 when that date representation will fail, but in ToodleDo's case perhaps the wrapping is happening even earlier?

I just checked, and the last date Toodledo will let me enter for any task is Jan 18, 2038. Anything beyond that just becomes no date. So I guess the problem is if you enter the date through another program, and sync with Toodledo, or maybe it is only recurrences. Anyway, that seems to be the threshold.
And I think garyo is correct about the 32 bit representation of time. http://en.wikipedia.org/wiki/Year_2038_problem

Yeah, we don't do anything special, we just use the built in representations of time that our software has. Hopefully people smarter than us will update the software that we use before 2038 comes around. We are flattered that people foresee themselves still using Toodledo in 30 years. I think we'll all have computers in our brains by then, but if there is a need for Toodledo to still exist in 30 years, we'll certainly keep it going and figure out some way to make due-dates work.

In the meantime, if you really need to schedule a task for beyond 2038, I suggest setting it to Jan 18, 2038 and then putting the real due-date in the note field.

Indeed switching to a different date representation is not that easy, though there are proposals and methods (using an unsigned for time_t is one, 64-bit value is another).

In the interim, perhaps it would be helpful to clamp time_t values to the valid range, on the theory that even if it makes them not correct at least they're still in the future?

if (t1 + tdiff < t_1970)
tresult = t_2038
else
tresult = t1 + tdiff

Another possibility would be to use Julian Day numbers instead of Unix timestamps... but that's more work.

And while we may not be using ToodleDo in 30 years, it's entirely possible that the ToDo lists we make today will get ported forward to other systems. Mine comes from PalmOS in the '90s originally, and that's where I originally entered my 10-year repeating passport expiration reminders. So it's not all that unreasonable to enter a date far in the future for a ToDo.

64 bit time is no solution. If you read that Wikipedia article, you will see that they too will have a time rollover on Sunday, December 4 of the year 292,277,026,596. So you're just prolonging the inevitable. :)