timeZone in checkin

Question

En regardant les documents, il existe une différence entre les données d'un objet checkin pour l'API de requête et l'API push en ce qui concerne timeZone.

Selon https://developer.foursquare.com/overview/realtime une poussée de l'échantillon contiendra le nom du tz par exemple en Amérique/New_York

Toutefois, selon https://developer.foursquare.com/docs/responses/checkin (et l'explorateur API) un objet checkin contiendra le décalage horaire par exemple 60 pour GMT + 1

Je n'ai pas réussi à confirmer quoi dans l'API Push moi-même, car je dois configurer les certificats SSL, quelqu'un peut-il confirmer que les documents sont corrects et nous avons en effet 2 types de format tz. J'aurais pensé qu'inclure le timeZone plutôt que le décalage serait mieux car cela ne varie pas avec Daylight Savings contrairement à la figure. Europe/Londres sera toujours une constante où le décalage basculera entre 0 et 60 minutes

Answer 1

Je ne suis pas directement familier avec l'API de FourSquare, donc je ne peux pas confirmer ou infirmer cela pour vous. Mais je peux vous dire qu'il y a souvent des cas où vous utiliseriez les deux.

Il est autorisé de ne présenter un décalage que si les données représentent un moment particulier. Étant donné que la réponse checkin fournit une date/heure createdAt sous la forme d'un nombre entier de secondes depuis epoch (alias «horodatage Unix»), il convient alors de fournir un décalage distinct. (Bien que je trouve intéressant qu'ils fournissent l'offset comme une chaîne et non comme un nombre entier de minutes.) L'autre manière que vous pourriez faire ceci serait avec un seul DateTimeOffset valeurs, habituellement présentées dans le format ISO8601, comme dans 2013-06-02T01:23:45-07:00. Les deux sont acceptables. Mais, comme vous le savez peut-être, un décalage n'identifie pas uniquement un fuseau horaire. Dans le cas d'un événement unique, ce n'est pas nécessaire. Mais si c'était événement récurrent, ou s'il y avait une possibilité que vous voulez modifier la valeur de temps, alors un décalage seul ne suffirait pas. C'est quand vous avez besoin de l'identifiant complet de la zone.

Si vous disposez d'un identificateur de zone tel que America/New_York, vous pouvez toujours rechercher le décalage correct pour une date/heure quelconque. Mais tout le monde n'a pas une implémentation TZDB facilement disponible. Par exemple, dans .Net sous Windows, vous obtenez par défaut la base de données de fuseaux horaires maladroite de Microsoft, et vous devez trouver une bibliothèque (comme NodaTime) si vous voulez utiliser les zones TZDB.

Il semble étrange que le push et pull pour le même type d'action (un check-in) aurait des valeurs différentes simplement parce qu'ils traversaient différentes API. Mon conseil (à Foursquare) serait triple:

• Soyez cohérent sur les données de la même activité, quel que soit poussée vs traction.
• Indiquez à la fois l'identificateur TZDB et le décalage UTC associé à l'événement.
• Indiquez l'horodatage et le décalage de l'événement en une seule valeur, sous la forme d'une chaîne au format ISO8601, plutôt que d'un entier de temps unix.

Answer 2

La documentation de Foursquare est correcte mais un peu incomplète (au moment de la publication). La réponse d'enregistrement contient un champ timeZoneOffset. La réponse push en temps réel a un champ et un champ timeZoneOffset. Le champ timeZone est toujours présent pour les besoins hérités.

Merci de l'avoir signalé; nous mettrons à jour les documents pour refléter que timeZoneOffset est la méthode préférée à ce stade. Comme Matt l'a mentionné, la méthode de décalage est une meilleure façon d'identifier une heure particulière de createdAt.