Badge de dévot et fuseaux horaires, assouplissement des exigences ?

Contribuer Fonctionnalité
1

J’ai reçu quelques rapports d’utilisateurs concernant le badge Devotee, qui nécessite 365 jours de connexions consécutives pour être obtenu. Le problème semble être que les utilisateurs situés dans des fuseaux horaires très éloignés de l’UTC (par exemple, PST +8) doivent tenir compte du fait que le « jour » sous-jacent est basé sur l’heure UTC. Nous constatons que des utilisateurs européens obtiennent le badge, tandis que d’autres ne comprennent pas pourquoi ils ne l’obtiennent pas.

Je pense que ce qui s’est produit, c’est qu’un utilisateur situé par exemple en PST +8 se connecte tôt le matin du 14 mars, puis tard dans la nuit du 15 mars (ce qui, pour lui, représente une connexion chaque jour), mais la requête système pour le badge considérera le 15 mars comme entièrement « sauté », rompant ainsi sa série de 365 jours consécutifs. Cela peut être décevant pour l’utilisateur final, surtout s’il est proche de la fin de son année de « série ».

Je sais que les fuseaux horaires et les requêtes de base de données ne fonctionnent souvent pas bien ensemble, mais je me demande s’il serait possible d’élargir la requête, peut-être pour accorder une tolérance à un « jour UTC » lorsque les périodes d’obtention du badge sont plus longues, comme une année — merci.

9 « J'aime »
2

La table qui stocke les visites utilise une date simple, et non un horodatage, ce qui rend impossible la mise en œuvre d’une tolérance de quelques heures.

Tout dépend de ce que votre communauté souhaite à la fin. Vous pourriez désactiver ce badge et créer un badge personnalisé équivalent qui se déclenche avec moins de jours, afin de couvrir suffisamment cette période. Ou alors, vérifiez les utilisateurs dont les écarts entre les visites ne dépassent jamais un jour.

7 « J'aime »
Devotee Badge Issue!
3

Merci d’avoir regardé et de votre réponse.

Ils veulent que leur badge fonctionne indépendamment de leur fuseau horaire. Les utilisateurs de longue date sont les plus passionnés. :slight_smile:

Nous avons une requête Data Explorer comme celle-ci, qui nous a aidés à identifier le problème :

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

…ce qui donne les segments continus listés. En raison de la partie UTC (ou plutôt de la façon dont la date sous-jacente est stockée plutôt que le datetime ?), il semble juste que nous devions attribuer le badge, même si un « écart d’un jour » existe, je pense.

Nous allons essayer de créer un autre badge Dévot basé sur la modification de cette requête, peut-être avec un INTERVAL de ‘2 jours’ ?

6 « J'aime »
4

Nous recevons quelques demandes d’assistance concernant le badge Dévot pour cette raison exacte. La solution de contournement consiste à attribuer le badge via la console Rails. Les instructions pour le faire sont disponibles ici : Award a non-custom badge through the console.

S’il existe un moyen simple d’assouplir les critères du badge pour permettre quelques jours d’interruption, je pense que ce serait une bonne idée.

5 « J'aime »