I have a goal with a deadline set to 4pm. Yesterday I added a data point after 4pm. It’s value was 2 and the date was 2014-12-08. Today I added a data point before 4pm. The data point had a value of 9 and date 2014-12-09. Adding this data point somehow modified the date of the previous data point from 2014-12-08 to 2014-12-09. In case it is relevant, note that I am adding the data points using the create_all API method.
David, this sounds super weird, so I took a look at the logs and I think that the second datapoint you added was a red herring. The date change on the first datapoint shows up in the logs as a separate edit event that happened a good 30 minutes after adding the second datapoint. Could this be a re-occurence of ‘EDT’ here Arbitrary Deadlines: Buglist (unintentionally changing the date when you edit a datapoint), or do you recall any other edits you made to the goal around 14:23 today around which I could look for weird side-effect bugs?
B
1 Like
I did a manual edit yesterday to fix the first data point. That is, after I noticed that the date of the first datapoint changed from 2014-12-08 to 2014-12-09 I manually edited that datapoint to correct the date back to 2014-12-08. I think I did that manual edit at around 14:23h CET. This is probably the edit you see in your logs. Nevertheless, I think you are right about the second datapoint being a red herring because some of my datapoints changed their date again, even though today I have not yet submitted anything. The datapoints whose date changed were again datapoints I entered after the deadline, i.e., after 4 pm.
My scripts keep their own simple logs. This is what they recorded:
2014 12 06 1 "Make writing journal paper the new priority goal"
2014 12 08 2 "Read "Basic mathematics" by Serge Lang"
2014 12 09 9 "Write draft of itemized journal paper"
2014 12 09 1 "Write draft of itemized journal paper"
2014 12 09 1 "Read about SPB"
2014 12 09 1 "Read "Basic mathematics" by Serge Lang"
However, what I see in my “All Data” tab is the following:
You’ll notice that the last two datapoints have a date of 2014-12-10 instead of 2014-12-09.
Wait! I just downloaded a TSV export of my data and this export has the correct date for the last two entries:
$ tail -n 6 datapoints.tsv
2014-12-06 1.0 "Make writing journal paper the new priority goal" api
2014-12-08 2.0 "Read "Basic mathematics" by Serge Lang" api
2014-12-09 9.0 "Write draft of itemized journal paper" api
2014-12-09 1.0 "Write draft of itemized journal paper" api
2014-12-09 1.0 "Read "Basic mathematics" by Serge Lang" api
2014-12-09 1.0 "Read about SPB" api
Maybe the “All Data” tab is just formatting the dates incorrectly? Maybe it is a timezone issue?
2 Likes
@bee A similar thing is happening with the android app. Under my graph I see the date of the last two entries as 2014-12-10:
When I click on “All data” on the app, I see the correct date:
2 Likes
Probably related bug report regarding from @dreev:
This now seems to be reproducible: On my d/sugar (do-less)
goal, if I let the PPR happen, it persists in showing as date+1 on
beedroid but is correct on the website. I had a PPR on the 8th, shows
up as the 9th on beedroid. I entered an explicit value for the 9th in
beedroid and it didn’t overwrite the PPR and does show up as the 9th
on both beedroid and web.
Bethany, maybe we just forgot to do the under-the-wire trick for the
timestamp of the PPR datapoints?
1 Like
What does PPR stand for?
Oh, sorry, ‘PPR’ => pessimistic presumptive report, for do less goals. Danny was noticing a discrepancy between the dates shown in the android app and those in the website, but only for his do less goal.
Clarification: is the log from your script showing the input that was sent to beeminder?
Bethany
Yes. It is a log of the data I sent to beeminder using the create_all API method, with the exception that I did not log the full timestamps submitted, but instead just logged the date, i.e., the timestamp formatted as'%Y %m %d'.
Ok, diving into this in a little more depth, I want to confirm from @saranli whether the “All data” listing in the app is using daystamps or doing something else to come up with the dates it is displaying.
It looks like the website and recent data in the app agree about the dates. (Correct?) – What I think is going on here is that the second two datapoints you’ve submitted on 12/9 were after the goal’s deadline, which is why we’re counting them as the next day. If you submit a timestamp we take it as is and then figure out which “day” that fell on, given your timezone and your goal’s deadline. If you submit a date (which is essentially what happens with e.g. the email interface), we use that date and pick a timestamp that falls on that “day” – but again with day being considered as from one deadline to the next, so not necessarily from midnight to midnight.
2 Likes
Yes, both the website and the beedroid app show the same (incorrect) date if I look at the data the day after the corresponding data points have been entered. If I look at the dates the same day that the data has been entered, then the dates are correct.
Yes. Only datapoints submitted after the deadline change their date the next day.
1 Like
I believe this is fixed in the latest version of the Beeminder Android app. Thanks so much for the bug report and keep letting us know whenever you see something potentially fishy!
My issue is not yet fixed.
In the android app the dates now seem to be consistent, i.e., I see the same date under the graph and in the “Data Points” tab. But the date that I see is sometimes incorrect. Specifically, it is incorrect if the datapoint was submitted after the deadline on a given day and is displayed on a subsequent day.
More specifically, the deadline for my goal is 4 pm. If I submit a datapoint on day X before 4 pm, then on day X+1 the date of the datapoint is displayed as X both on the website and the android app, as expected. If I submit a datapoint on day X after 4 pm, then the datapoint is displayed correctly during the remainder of day X. However, on day X+1 onwards the date of the datapoint is displayed as X+1, instead of X.
Latest example:
Yesterday (2014-12-30) after 4pm I submitted the following datapoint:
2014-12-30 2.0 “Read “Basic mathematics” by Serge Lang”
Yesterday this datapoint was displayed with the correct date (2014-12-30) on the website and android app. Today (2014-12-31), if I look at the same datapoint (in the android app or website) it is displayed with date 2014-12-31. So the datapoint changed its date overnight.
Note that the data export from the website, OTOH, shows the correct date (2014-12-30). So the date shown in the data export (which is the correct one) is inconsistent with the one shown on the website and android app.
2 Likes
Ah, thank you so much for the details! Inconsistency means definitely a bug, but we have to decide which is correct. I contend that a datapoint timestamped after the deadline should in fact always show the next day’s date. See section 4 (and if you really care, the appendix) of the midnight spec. If you explicitly enter a datapoint as, say, the 30th (like by typing “30” for the date) then it should always display as the 30th. That much I believe is now true.
To gauge urgency, is this throwing you off or causing other problems?
Thanks for the link. I did not realize that this date shifting of data points entered after the deadline was on purpose. It was certainly not what I expected.
The date inconsistency between the data export and the website/android app is not causing any problems. The date shifting is not really causing problems either. It was just unexpected and I wonder if there isn’t a less confusing solution. Maybe it would make sense to introduce a concept like a “virtual day” (a 24h interval that goes from deadline to deadline). For a data point you would then say that it was entered on such a date (the date of the timestamp without any date shifting) and say that the data point falls on the Nth virtual day if N - 1 deadlines have elapsed since goal creation. But maybe this is even more confusing (especially since the virtual days for different goals might not align because they may have different deadlines and because the virtual days would have to be shifted around if a deadline is changed).
3 Likes