This post inspired by the following comment:

Come up with a better way to do [enthusiast/fanatic tracking] (that doesn't involve users having to set a timezone) and make a feature-suggestion. – Robert Cartaino (source)

User profiles have a "last seen" field, so the sites clearly already track the time of last activity. I propose adding a date/time field for all users representing the moment at which they start their journey towards Enthusiast/Fanatic. Let's call it startOfConsecPeriod for now. Whenever a user performs enough activity to trigger an update to the "last seen" field, run something roughly* like this:

// If it's been more than a day since the last visit, reset the clock
if(currentTime - lastSeenTime > TWENTY-FOUR_HOURS) {
    startOfConsecPeriod = currentTime;
}

lastSeenTime = currentTime;
amountOfTimeWithoutMissingADay = currentTime - startOfConsecPeriod;

// Check for badges
if(!userHasFanatic && amountOfTimeWithoutMissingADay > HUNDRED_DAYS)
    awardFanatic();
else if(!userHasEnthusiast && amountOfTimeWithoutMissingADay > THIRTY_DAYS)
    awardEnthusiast();

No muss, no fuss, and most importantly, no time zone tracking. Feel free to use UTC; this method doesn't care. Users can traipse around the world in any direction they choose; this method doesn't care. Pegging the concept of a "day" to the user, not some arbitrary clock, really simplifies matters.

* I emphasize "roughly" because this pseudocode is supposed to be illustrative, not efficient or elegant.

share|improve this question
    
+1 I had the same idea –  David Z Jun 30 '10 at 17:44
2  
I had a further thought. There are a couple of extreme possibilities for timezone independence: the badge could be awarded for any access pattern that hits every calendar day in any timezone (this rule would allow up to 48 hours between visits under certain circumstances), or for only access patterns that hit every calendar day in every timezone (that would be the original 24-hour suggestion). Or there could be some compromise between the two extremes, e.g. the 36-hour suggestion. Do we want to go for one extreme or the other, or neither? –  David Z Jun 30 '10 at 17:55
1  
I think David's "...awarded for any access pattern that hits every calendar day in any timezone..." is the best idea (and the one that I first though of when I saw the original "inspired by" post. Basically the system can try to find the time zone (or arbitrary 24h rollover point) that gives you the longest current string of consecutive days, and recalculate it if you miss a day. Fair to everyone across the globe, maybe not too much work, and the system can tell users their window so they know where they stand. –  Rawling Jul 2 '10 at 8:30
    
And of course, it's the answer I typed up before noticing these comments, too. Clearly the best. Well, here's your chance to vote on it! –  eMansipater Sep 30 '11 at 20:05
add comment

3 Answers

There is still a small issue.

To me, if I visit a site in the morning, and then visit it again the next day any time after I visited the previous day, more than 24 hours have elapsed. And, I would be done with consecutive days.

Hypothetical:

On Fridays I check SO in the morning, but on Saturdays at night. Thus, I could never be eligible to earn the badges.

More hypothetical:

Here is a typical week perhaps:

Monday    SO at 8:00am  
Tuesday   SO at 8:00am  
Wednesday SO at 8:40am -- Streak ended

Possible solution, allow for 36 hours between visits.*

share|improve this answer
    
A way to solve this may be to allow for 36 hours... –  jjnguy Jun 30 '10 at 17:30
    
The effect is that this favors those who are some degree of active on the site (i.e. first check-in in the morning, then check-in again at night) instead of merely "visit at least once X days in a row". –  Grace Note Jun 30 '10 at 17:31
2  
@Justin: Hm, yes, I focused too much on pegging the day to the user. I suppose a hybrid system could be implemented, but it would likely be far too confusing. With the 36-hr system, a user could visit Friday night and Sunday morning and still qualify, missing both a 24-hr block and a calendar day. +1, back to the drawing board... (actually the lack of a drawing board was probably the issue here). –  Pops Jun 30 '10 at 17:31
    
This is true, the proposal does change the requirements for the badges in a way that makes them harder to get. Of course, there is always the option to just accept that - there's no inherent reason the badges have to be based on UTC days, the way they are. (And the current system has a small issue too: using the same hypothetical situation, if I check on Friday morning e.g. 9AM and Saturday night e.g. 10PM, I'd miss a day, since I'm UTC-4) –  David Z Jun 30 '10 at 17:34
    
@Grace, come to think of it, that's not a bad behavior for the badge to encourage. –  Pops Jun 30 '10 at 17:35
1  
@Popular Demand (3 comments up): given the same access times (Friday night and Sunday morning), another user in a different time zone might not be missing a calendar day. I think the point here is to remove any dependence on the local calendar, and as a necessary consequence, it becomes either globally possible or globally impossible for users to miss one calendar day and still get the badge. –  David Z Jun 30 '10 at 17:36
    
@DavidZaslavsky if done right it could be made so that the user has to miss the same timeframe relative to the daily schedule throughout their 30-day (or greater) run. So the user would only be able to do the Friday night/Sunday morning trick if they do not (ever) also do the Sunday morning/Monday night split as well (or any corresponding one throughout the week). I'll post a more thorough explanation as an answer. –  eMansipater Sep 30 '11 at 15:40
add comment

I think there is a simple and more effective way to track this that will both align with users' natural intuitions and prevent gaming/misrepresentation. The idea is to simply track the greatest number of consecutive days possible in any single timezone, and reset the count once the user's visits could not be considered consecutive no matter where they are. Because it's equally hard to visit consecutively in any particular timezone, the method leaves no geographic bias and auto-correlates to any kind of daily schedule the person might have.

There's definitely a better way to program this, but going for readability here I'm going to parallel your method and use some vague pseudocode. Here is how it would work out:

Add the date/time field for all users representing the moment at which they start their journey towards Enthusiast/Fanatic, and call it startOfConsecPeriod. Also add a field storing possibleTimezones and a method called impossibleZones(startAbsence, endAbsence) which returns timezones with more than 1 day division in the given range. Whenever a user performs enough activity to trigger an update to the "last seen" field, run something like this:

// If it's been more than 48 hours since the last visit, reset the clock and list
if(currentTime - lastSeenTime > FORTY-EIGHT_HOURS) {
    startOfConsecPeriod = currentTime;
    possibleTimezones = impossibleZones(currentTime, currentTime + FORTY-EIGHT_HOURS);
}

// If it's been more than 24 hours since the last visit, remove incompatible timezones
if(currentTime - lastSeenTime > TWENTY-FOUR_HOURS) {
    possibleTimezones = possibleTimezones - impossibleZones(lastSeenTime, currentTime);
}

// If no compatible timezones left, reset the clock and list
if(possibleTimezones == 0) {
    startOfConsecPeriod = currentTime;
    possibleTimezones = impossibleZones(currentTime, currentTime + FORTY-EIGHT_HOURS);
}


lastSeenTime = currentTime;
amountOfTimeWithoutMissingADay = currentTime - startOfConsecPeriod;

// Check for badges
if(!userHasFanatic && amountOfTimeWithoutMissingADay > HUNDRED_DAYS)
    awardFanatic();
else if(!userHasEnthusiast && amountOfTimeWithoutMissingADay > THIRTY_DAYS)
    awardEnthusiast();

No muss, no fuss, no time zone tracking, no increased difficulty to achieve, no reduced difficulty to achieve. Definitely UTC; this method begs for it. Users who travel can pick any one timezone to go by, and as long as they stick with it they'll be fine. Users can log in any time of the day they want, even 12:01 AM one day and 11:59 PM the next (though in so doing they've locked themselves into only one possible timezone so they can now never miss a day in it again).

Most importantly, the typical case where a non-UTC user logs in at one time on one day and a couple hours later the next is fully covered in all timezones. You wouldn't have to explain to users how the method works--it would just automatically follow their intuitions for days in their local timezone. It's also not gameable because the only way of gaming it is to religiously follow some timezone other than your own (whether you realise you are or not).

share|improve this answer
add comment

In response to Justin's answer I propose that we allow both methods of tracking. So let's call the current method "old method" and the proposed method "new method"

Say you have a streak that looks like this:

Monday    SO at 8:00am  
Tuesday   SO at 8:00am  
Wednesday SO at 8:40am -- ended according to new method, but valid according to old
share|improve this answer
1  
What would be the point? Is there some access pattern that would be valid under the new tracking method but not under the old method? –  David Z Jun 30 '10 at 17:43
    
No dice, if you're in US Eastern you could visit at 1600 Thursday and 2200 Friday and still lose. The admins are unwilling to implement user-specific timezones -- which I support, I might add -- so I'm more and more leaning towards a purely user-based "day." –  Pops Jun 30 '10 at 17:43
add comment

You must log in to answer this question.

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