Calender day or goal day shortcut?

[insti]

When entering data for a goal you can use ‘^’ as a shortcut to the current day.

There are 2 ways this could work, by calender day or by goal day.

When using goal day, if your deadline is before midnight, and you enter data after the goal deadline it uses the next day’s date for the data point.

The alternative is calender day which would report the date of the current (timezone dependent) calender day.

If your deadline is midnight, the 2 methods give the same result.

Currently Beeminder interprets a caret ‘^’ as goal day.

Reply with which one you would prefer and any opinions on why either is clearly wrong.

[insti]

I’d prefer it used calender day.

I have a lot of goals that are (happily) in the green, and thus it is not imperative that I enter the data for them before the deadline, so I will often enter data last thing at night which tends to be after my deadlines, I would like this data to be attributed to the calender day.

I have never wanted to enter data for the next calender (or goal) day.

[scarabaea]

I have started to write a lengthy reply about how I generally agree “but” there are marginal use-cases and about how in these marginal cases using calendar date might spoil everything - but while writing I realized that I am wrong, and, indeed, in any case I use non-midnight deadlines, the calendar date will still do the thing.
The only case (which I do not use) is a night-owl deadline. If understand this idea correctly, this is about wanting to have the datapoint for the previous date than the actual calendar date. With early-bird deadline entering the datapoint for either the goal date or the calendar date will do the same thing in terms of giving some more buffer.

[dreev]

From an implementation perspective goal day makes everything nice and elegant. I’ll quote myself in another thread:

Earlier deadlines unfriendly to QS info (i.e. data is incorrect)

We agonized about this a lot when implementing arbitrary deadlines. See section 4 + the appendix of the arbitrary deadlines spec. Short answer is that the data has the true timestamps but we do treat the deadline as the day boundary for purposes of graphing and displaying. It became a worse-is-better vs the-right-thing debate and I predict @mary will be horrified that we rejected “the right thing” but, well, read about the worse-is-better philosophy before yelling at us too much… (: PS: Speaki…

And later in that same thread, this:

Earlier deadlines unfriendly to QS info (i.e. data is incorrect)

This is convincing me that, at the very least, @philip is right that the CSV export should include the calendar dates. That might be a nice simple #UVI in fact. (No separate export though, just throw in an additional column.) @chipmanaged, you are amazing. Thank you so much for the incredibly thoughtful feedback. Until we get to this, I think the workaround, as you suggested, is to stay hyperaware of the deadline as end-of-day and remember to enter data after it as “yesterday”. Also I just rem…

Interested to hear if you think adding an additional column in the CSV export with calendar day would make this feel less wrong.

[insti]

@dreev

Interested to hear if you think adding an additional column in the CSV export with calendar day would make this feel less wrong.

Not really, as I was only concerned about the input use case.

@scarabaea made a good point about night-owl deadlines (assuming that these work correctly, I’ve not personally tested them.)

I do now think that goal day is the right thing to do in the general case.

But I would still like to be able to choose which is used (per goal).

[byorgey]

Measuring Time Is Really Hard ™. Personally I doubt whether there is really any “right” way to do this, and I can imagine scenarios where I would want one or the other. Choosing which input method is used on a per-goal basis would maximize user utility, I suppose, but probably at a very large cost in terms of code complexity, not to mention user cognitive load and questions to support. I’m not sure that would be worth it.

I do think doing it by goal day rather than by calendar day is a sensible default. Incidentally, this never really trips me up because I use the Android app for entering most data points, where I can clearly see the numeric date for which it will record a data point when I hit “submit”. So e.g. I have several goals with a deadline of noon, and sometimes I do them in the morning but forget to enter the data point until after noon — in that case I always notice that the numeric date is for tomorrow and decrement it before hitting “submit”. So maybe a #UVI would be to have some similar sort of indication next to entry boxes on the website, where it shows you what “today” is (e.g. it could say “Submitting data for Thednesday, Fruvember 34” or something like that).