It is a warm summer night, you sit in your recliner and enjoy a hot cup of coffee right before midnight.
Except you are not because it’s winter right now, who would drink coffee that late (let’s not be silly) and also you are horribly akratic and skating the edge of your YBR.
But it is shortly before midnight.
And thus you’re at your laptop, the beeminder bot just stopped bugging you that there’s 5 minutes missing because like the Pro you are you just barely squeezed enough productivity out of the last minutes of this day to make the bot happy and your goal not derail.
But you keep going! You hit Start in the beeminder app once again and 15 minutes past midnight you log that data point, finally giving in to the sweet lure of being done. For today.
At peace with yourself and the world you finally relax in your recliner and take a look at your dashboard. The app logged 17 minutes on this new day even though it’s just 00:15. How interesting! Except not really because you hit Start at 23:58 and even @shanaqui’s bunnies can do that math. So that’s where those two minutes came from. Mystery solved. Case closed? I hope not for if the app would reflect that people use the stopwatch “across” the deadline… that would be nice attention to detail would it not?
I don’t know. I’m not convinced this is exactly a “bug”. It’s doing a pretty sensible thing, given the inputs, and I could make an argument that trying to do something more clever would be more confusing. It doesn’t seem right to stop or split the timer for the user just because the arbitrary day boundary happens to have been crossed. We have given ourselves the constraint that we have to pick a specific date for the datapoint, so picking the date of the end of the timer is just as reasonable as picking the date at the end…
Would splitting the timer be confusing? After all the stopwatch models a timespan, not an instant. And while it is ticking, time elapses in which the arbitrary deadline the user set might have been crossed.
If you leave this stopwatch running for 1hr, 2hrs, 3hrs and you just happen to have crossed your arbitrary point in time where it is a “new day” for your goal some time during that… you better remember when exactly you started so you can manually enter that data correctly because the stopwatch won’t.
And isn’t the idea behind the stopwatch to not have to remember when you started?
At the very least right now you have to remember that you did cross that point in time before you tap “Add datapoint” in the app. And you get no indication that you did cross it. Definitely not while in the stopwatch. And exiting the stopwatch screen to check either loses or risks losing the time tracked.
Maybe this helps to figure out what to do about this.
@bee@phi Say you’re meditating and you need 10 more minutes that day to reach your goal. Because you’re super akratic, you start the timer just in the nick of time, a few seconds before 11:50.
You’ll derail, even though you get your 10 minutes in before midnight, because you didn’t stop the timer in time. Yes, this can be fixed by writing support, but it’s frustrating to the user to worry about whether the logged time will count on the correct day or not, and to see and deal with an incorrect derail.
Oh and @bee, I didn’t mean to turn this into some sort of discussion. Mea culpa. You know of the issue know, that’s all I wanted Also discourse needs more bee emojis.
I’m with @bee, that sure sounds like the expected behavior! Or at least what worse-is-better dictates. The goal derails at the deadline and shouldn’t try to be so clever as to be aware that there’s a timer still running that could’ve or should’ve been stopped and submitted in time. Like, just get the dang data in by the deadline and all is well!
Also discourse needs more bee emojis.