5

The Stack Exchange Data Explorer has a lot of useful data in its Votes table. Unfortunately, a lot of this data, and particularly the timing data, can be used to deanonimize voting patterns, which is definitely unwanted, so to this end vote timing information is coarse-grained to 1-day intervals. For upvotes and downvotes this is somewhere between a Good Thing and an essential for the site's functioning.

However, there's a bunch of other vote types in that table,

1. AcceptedByOriginator
2. UpMod (AKA upvote)
3. DownMod (AKA downvote)
4. Offensive
5. Favorite (UserId will also be populated)
6. Close (since 2013-06-25 close votes are ONLY stored in the PostHistory table)
7. Reopen
8. BountyStart (UserId and BountyAmount will also be populated)
9. BountyClose (BountyAmount will also be populated)
10. Deletion
11. Undeletion
12. Spam
15. ModeratorReview
16. ApproveEditSuggestion

and for a lot of those (a) timing information is public anyway (Bounty Start, Bounty Close) or carries no deanonimization risk (Accepted, Delete, Undelete). This timing data won't save the world by itself, but it is relatively useful for relatively interesting queries one can think of. (As an example, answers posted within n hours of a bounty being closed / awarded, or time-to-accept statistics over all questions.)

Is there some specific reason why all timing data is pared down, other than uniformity? Would it be very hard to make these sorts of vote types have precise timing data available in the data dump and data explorer?

3

For bountystart and bountyend you can (with a bit of care because SqlServer hates this query) recreate those date with times by joining the votes table with the posthistory table. You'll be looking for the Post notice added (33) and post notice removed (34) events.

This query gives a glimpse of what can be possible

select top 1000 v.postid as [Post Link]
     , v.creationdate as [vote date]
     , ph.creationdate as [post notice datetime]
     , ph.text
     , ph.comment
     , v.bountyamount
     --  v.userid as [User Link]
from votes v 
inner join posthistory ph on ph.postid = v.postid
where 
(   v.votetypeid = 8 -- bounty start
and ph.posthistorytypeid = 33 -- post notice added
)
order by v.creationdate desc

Post deletion and undeletion can be found directly in table posthistory, for posthistorytypeid's:

  1. Post Deleted - A post was voted to be removed.
  2. Post Undeleted - A post was voted to be restored.

Leaves us only with the Accept (and Unaccept?) events that can't be pinpointed up to the minute.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .