The akrasia horizon is seven days from “today”. But what does “today” mean? I’d hope it’s first of all in my timezone, and secondly taking into account the goal’s deadline. The global breaks page, the individual goal’s breaks page, and the API (thus also the road editor) are inconsistent about this, annoyingly so. Furthermore—is seven days from today exclusive, or not? Are there eight days in the akrasia horizon, or seven? If today is Tuesday, do we mean that within the akrasia horizon is Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday, Monday; or do we mean it to include Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday, Monday, Tuesday? (Or, as it would be in the yellow brick staircase world, seven days of time, with the horizon including the period until the same time of day next Tuesday, 24 * 7 * 60 * 60 = 604800 seconds from now? (except if there is an intervening DST change or leap second, in which case the number of seconds is adjusted accordingly, at least in the ideal yellow brick staircase world.))
I’d at least like a definitive answer to the inclusive/exclusive question, at least as to what the underlying intention is, because then I could identify which behavior is buggy and which is as intended. There’s at least some of each behavior. (See also.)
I think I have some bugs to report, but the situation is so messed up I don’t even know what is a bug and what is intended.
I can try describing them. At this point I’ve tried so many things it’s hard to untangle the various causes. Note that they interact, and so it’s hard to tell which a given test has uncovered.
A few of them:
The builtin graph editor (on the settings page), and the individual goal breaks page use a 7-day horizon (i.e. an exclusive one.) The graph.beeminder.com editor and the global breaks page use an 8-day horizon (i.e. an inclusive one.)
I think that maybe the builtin graph editor (and the API) are using server time (Pacific time?) and/or not accounting for the goal’s deadline (The way it should work: past early bird deadlines count as the next day, even if midnight hasn’t passed, and even if midnight has, if the deadline is a night owl deadline that hasn’t past, it shouldn’t count as the next day yet. In practice: the cutoff is always midnight, I think.)
The global breaks page definitely uses timezones correctly nowadays, but I’m not sure if it handles goal deadlines. I suspect not.
My main conclusion though is my question about what the akrasia horizon really means by “a week from today”. If we’re working in discrete days, rather than a continuous yellow brick staircase, we are presented with the question of if this is inclusive or exclusive. It would be really nice to have a single unambiguous answer about how things are supposed to work, even if they don’t all work that way right now.
I’m not as familiar with these as I used to be, but yes. These bugs definitely exist (well, a year ago they did). It would be great to get this definition locked in.
Something similar may be happening on the commitment dial at the website: set a rate and pick a date via the date picker. Save.
Return to the goal and again to its commitment dial. Adjust the rate. Save.
Reload the page. Notice the goal date has just moved back a day!
What you describe is actually closely related to the bug which originally started my whole quest here. Due to the above-listed additional issues along the way, I haven’t managed to fully isolate it, and it may or may not be one or another of these issues in disguise.
So far, this is what I’ve got to best isolate the issue:
Load the page and navigate to the settings tab.
Note the goal start-date in the (builtin) graph editor.
It will have advanced a day. Unless you hit the graph editor’s “save” button at this point, it won’t have an effect and thus won’t cause any harm. But woe betide anyone who then uses the graph editor to make other tweaks to their graph at this point without noticing and resetting the start date back to what it was manually.
I’ve untangled what happened a bit. I seem to have encountered three distinct bugs in succession, building on one another.
First, the above-described bug wherein the start date sneaks forward got one of my goals. This shifted my entire road downward, because on this goal so far all my segments had been with an end date and slope (without a end value), so the change propagated forward indefinitely.
Had this been a do-more goal, that would have meant it made the goal easier, and thus I’d have been allowed to fix it. But no, it was a do-less goal, so the bug made the goal harder.
Fine, I know I could ask support for help, but I was going to add an upwards discontinuity in any case in a week. Having done so, all I’d need to do is to wait for that day to come, and then I could fix my road retroactively. This is because the discontinuity jumps to a fixed value, so post-discontinuity the road slopes upwards from there, without reference to the earlier part of the graph. So moving the start date back to what it should be will then only make the past easier, not anything wihtin the akrasia horizon, and thus should be allowed.
Not so fast! Bug 2 I think relates to the discontinuity, maybe. I think I’ve encountered something like this before. On the day of the discontinuous upwards jump in the road, I should be able to adjust the start date while only making the past easier, but it won’t let me.
Neither will it the next day! That’s bug 3. It’s the next day for me, local time. But the road editor/API works exclusively in Pacific (?) time. So I have to wait until the afternoon, here in UTC+7, for the akrasia-horizon checking to have moved on to the next day and not be entangled with the previous bug any longer.
I hope this makes sense. I myself am not entirely sure of some of the stages here, given that the issue is compounded by multiple (apparently) different bugs.
