Distintivo Devotee e fusi orari, requisiti rilassati?

Contribuisci Funzionalità
1

Abbiamo ricevuto alcune segnalazioni dagli utenti riguardo al badge Devotee, che richiede 365 giorni consecutivi di accessi per essere ottenuto. Il problema sembra essere che gli utenti situati in fusi orari lontani dall’UTC (ad esempio, PST +8) devono tenere conto del fatto che il “giorno” di riferimento è basato sull’orario UTC. Stiamo osservando che gli utenti europei ricevono il badge, mentre altri non capiscono perché non lo ottengano.

Credo che quanto accaduto sia il seguente: un utente in un fuso orario come PST +8 potrebbe accedere la mattina presto del 14 marzo e poi la sera tardi del 15 marzo (per loro un accesso al giorno), ma la query del sistema per il badge considererà il 15 marzo come completamente “saltato”, interrompendo la loro serie di 365 giorni consecutivi. Questo può essere frustrante per l’utente finale, specialmente se si trova vicino alla fine del proprio “anno” consecutivo.

So che i fusi orari e le query di database spesso non si integrano bene, ma vorrei chiedervi se sia possibile fare qualcosa per “allargare” la query, forse introducendo una tolleranza per un “giorno UTC” quando si tratta di periodi più lunghi per il badge, come un anno. Grazie.

9 Mi Piace
2

The table that stores visits use a plain date, not a timestamp, so implementing a tolerance of a few hours is not feasible.

It all depends on what your community wants in the end. You could disable that badge and create an equivalent custom one that triggers with less days so it is enough to cover those days. Or check for users whose visit gaps are never more than 1 day.

7 Mi Piace
Devotee Badge Issue!
3

Thanks for looking and the response.

They want their badge to work regardless of their timezone. The long time users are the most passionate ones. :slight_smile:

We have a Data Explorer query like this, which helped figure out the issue:

-- [params]
-- user_list :users

WITH StartingPoints AS (
  SELECT user_id, visited_at, ROW_NUMBER() OVER(ORDER BY user_id, visited_at) AS rownum
  FROM user_visits AS A
  WHERE NOT EXISTS (
     SELECT 1
     FROM user_visits AS B
     WHERE B.visited_at = A.visited_at - INTERVAL '1 day' AND
     B.user_id = A.user_id
  ) AND user_id IN (:users)
),
EndingPoints AS (
  SELECT user_id, visited_at, ROW_NUMBER() OVER(ORDER BY user_id, visited_at) AS rownum
  FROM user_visits AS A
  WHERE NOT EXISTS (
     SELECT 1
     FROM user_visits AS B
     WHERE B.visited_at = A.visited_at + INTERVAL '1 day' AND
     B.user_id = A.user_id
  ) AND user_id IN (:users)
)
SELECT u.username, S.visited_at AS start_range, E.visited_at AS end_range, (E.visited_at - S.visited_at + 1) AS Days
FROM StartingPoints AS S
JOIN EndingPoints AS E ON E.rownum = S.rownum
JOIN users u ON u.id=S.user_id AND
u.id IN (:users)
ORDER BY u.id ASC, S.visited_at DESC

…which gives the continuous segments listed. Because of the UTC part (or rather how the underlying date is stored rather than datetime?), it seems fair that we should award the badge, even if a ‘1 day gap’ exists I think.

We’ll look at trying to create another Devotee badge based off of changing this query, perhaps with a ‘2 day’ INTERVAL?

6 Mi Piace
4

We receive a few support requests about the Devotee badge for exactly this reason. The work around is to grant the badge through the Rails console. Instructions for doing that are given here: Award a non-custom badge through the console.

If there is an easy way to relax the badge’s criteria to allow for a few skipped days, I think that would be a good idea.

5 Mi Piace