I felt the same way. 
My first thought on reading the example was, “YES! PERFECT.”
1 Like
I’d get very confused if it didn’t tell me the actual number of days, as in calendar days.
You can still work on it during the other days, though. It just can’t derail on those days, and the slope is 0, but you should still be able to enter data.
@drtall, @grayson: What if you have a goal due Monday afternoon? Should it really be in beemergency status all weekend?
Or, what if you have a goal with slope 0 on Weds and slope 0.1 on Thurs. Why should Weds have the clock off but Thurs have the clock ticking?
That would be ugly, I agree, but I think the idea is that this way, it will already be in beemergency status before the weekend, and you’ll work to get it out of beemergency before weekend hits.
This had us super confused for a while since you don’t actually have the new YBHP setting turned on, so nothing should’ve changed for you (yet). Are you sure that you are seeing different behavior even without YBHP turned on? Recently different?
1 Like
I feel like “[the] sense in which that’s really 1 day of buffer and orange” is the only sense!
I am kind of feeling like a crazy person. I’ll just try one more time and then be done try to persuade people.
I wonder, do we not actually agree on what a safety day is? My definition of “safety day” is roughly:
A day during which you could work on your goal, but you won’t derail because you accumulated a buffer.
For a Weekends Off goal, a Saturday can’t be a safety day. It’s impossible to derail on a Saturday. You’re not spared the derail because you have a buffer; you didn’t “spend a safety day” every Saturday you do 0 on the goal. You’re spared the derail because weekends don’t exist. It’s a day for which the goal doesn’t apply in any sense whatsoever.
Try counting the number of hours to derail instead of days. If it’s 00:00:01 Friday and the goal derails 23:59:59 Monday, you’ve got 47.99 hours to work on the goal. That’s orange in the world I’m from.
I don’t care about “safety days” - that’s not a useful or meaningful measurement to me. I’ve never thought of the widgets as listing a number of safety days. I’ve always thought of them as listing the actual amount of time I have left.
What I care about is the number of actual days, calendar days, till my goal derails. That’s the actual amount of time I have to work on the goal until I get charged. I can do whatever I want with that time, work on the weekends or not, but at the end of that time if I didn’t do the task I’ll have to pay.
I agree with @dreev that Beeminder should just tell me how long I have and let me do the planning, and not try to be clever and confuse me by changing the time measurement in a non-obvious way just because I set weekends off.
It’s like the dress that appears different colors, or the Laurel/Yanny audio file - apparently to some people it’s obvious that the widget should say “3d” when you have 3 calendar days to go, and to others it’s obvious that it should say “1d.”
The problem is that weekends-off goals aren’t necessarily clearly marked as such, so seeing that “1d” would be misleading and alarming when you really have all weekend to do it - 3 calendar days.
I want to be able to plan what I do over the weekend and the next week, and to do that I have to be able to see the exact amount of time I have till derailment. Let me figure it out from there.
Also, your approach doesn’t nicely generalize - what happens when it’s no longer binary on/off days, but the slope is 0 on Weds and 0.1 on Thurs? Do we count Thurs as a tenth of a safety day?
2 Likes
But in actual fact, you do have 96 hours to work on the goal. Beeminder shouldn’t pretend that that time doesn’t exist when it is actual time that will pass and you need to plan how to best use that time.
2 Likes
Ooh, this could be another case study for my future article on The Anti-Magic Principle (rough notes thereon). What is the dumbest, most predictable thing Beeminder could do? Just a plain old countdown. No attempt to be clever and factor in upcoming breaks.
2 Likes
Can I check that somewhere? I know that something changed maybe 1 or 2 (3?) months ago and since then I’ve been working on weekends fairly regularly as a result. I raised once or twice in support emails, but I was told that the feature was being retired / deprecated or phased out. For a while I could still use the iPhone and iPad apps which continued the old functionality (of colouring that respected the weekends-off) but last week that was also phased out and so now there’s nowhere to find that functionality. (Hence my post here).
2 Likes
@strickvl, did you perhaps change the absolute lane width parameter on your goals 1 or 2 months ago? (It’s under Custom at the bottom of the Settings tab. If that doesn’t sound familiar, then this isn’t it 
)
1 Like
I don’t recall doing that. I looked there just now in a few goals and I see some very large numbers in there, greyed out. I don’t really understand what that does, but I didn’t change anything there.
1 Like
I can’t agree. If Beeminder is going to treat me like I have more time than I do, there was nothing gained by Weekends Off that wouldn’t have been accomplished by some dumb script to flatten the road automatically.
The mistake here is thinking that the slope of the road being 0 is the same as the day being a day off. This is related to the above comment as well. If I have a goal that is Weekends Off that also happens to have 0 slope on a Wednesday, the Saturday and Wednesday are not equivalent. For example, a Retroratchet should be able to gobble up the flat road on the Wednesday but it cannot alter the Saturday.
Edit: To be clear, the “yellow brick road” data structure is insufficient to represent what I claim is the ideal implementation of Weekends Off and I think that is why there are so many bugs related to how Weekends Off interacts with other parts of the product. When you treat Weekends Off like just another 0 slope brick you end up with lots of problems. Maybe I’m not right about what colors things ought to have but I’m pretty sure I am right about this much.
Was this ever not the case? 
@drtall, agreed, that’s the True Breaks project. Item #2 here:
1 Like
I have just discovered that there is still a vestigial part of the old way of being in the Beeminder code. (I hesitate to describe it here lest you take it away from me, but perhaps it helps me in the meanwhile).
Even though the full goal borders don’t turn blue when a goal is due, I have realised that the dot that is currently positioned showing the current status of the goal moving up (or down) the graph actually DOES show the colour (blue or orange) that takes into account weekends off etc etc as described above.
A wonderful early morning discovery.
1 Like