Actually, I take that back. I don't think the isNaN check is related here, although I think you're right there's a subtle bug lurking there. The real issue is the time parsing and how timezones…
Really good catch on the loading spinner. Since I'm hosting it locally and the backend you built is so fast, I never even noticed that :)
A better idea would be to only do this if tasks…
Ah yeah that's a good idea, I can take a stab at changing the isNaN check to something like you suggested here later today
@konrad This happens on every version I tried, including main/HEAD. What timezone did you test it in? Like I mentioned in the PR description, it consistently happens to me with any negative offset…
An extra API call isn't ideal, but I would say it's worth the better user experience. Could try to make it smarter and only reload if the updated tasks changed a field that is currently being filtered on (e.g. if the task title is updated and the only active filter is on due date, don't bother reloading), but that seemed like it would be a little overly complicated.
@konrad Sorry for the super verbose PR description, wanted to try and give plenty of the debugging info I ran into. Let me know if there's anything else I can help do try and fix this!
