Distintivo Devotee e fusi orari, requisiti rilassati?

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

La tabella che memorizza le visite utilizza una data semplice, non un timestamp, quindi implementare una tolleranza di alcune ore non è fattibile.

Tutto dipende da ciò che la tua comunità desidera alla fine. Potresti disabilitare quel badge e crearne uno personalizzato equivalente che si attivi con meno giorni, in modo da coprire sufficientemente quel periodo. In alternativa, verifica gli utenti i cui intervalli tra le visite non superano mai 1 giorno.

7 Mi Piace

Grazie per aver guardato e per la risposta.

Vogliono che il loro badge funzioni indipendentemente dal loro fuso orario. Gli utenti di lunga data sono i più appassionati. :slight_smile:

Abbiamo una query di Data Explorer simile a questa, che ci ha aiutato a capire il problema:

-- [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 

…che restituisce gli segmenti continui elencati. A causa della parte UTC (o meglio, di come la data sottostante è archiviata piuttosto che come datetime?), sembra giusto che dovremmo assegnare il badge, anche se esiste un ‘intervallo di 1 giorno’, penso.

Valuteremo di creare un altro badge Devotee basato sulla modifica di questa query, forse con un ‘INTERVAL di 2 giorni’?

6 Mi Piace

Riceviamo alcune richieste di supporto relative al badge Devotee proprio per questo motivo. La soluzione alternativa consiste nell’assegnare il badge tramite la console di Rails. Le istruzioni per farlo sono disponibili qui: Award a non-custom badge through the console.

Se esiste un modo semplice per allentare i criteri del badge permettendo alcuni giorni saltati, penso che sarebbe una buona idea.

5 Mi Piace