Calendrier : le fichier ICS ne contient pas d'informations sur le fuseau horaire !

Bug
1

J’ai vu un autre post qui disait de poster ici pour une raison concernant le calendrier, mais je ne pense pas que Discourse ait quoi que ce soit à voir avec ce problème, mais nos posts sont fermés après 7 jours, alors YOLO !

En regardant la spécification du fichier .ics, je ne sais pas lequel nous avons besoin, mais il nous manque ceux-ci… c’est

  1. X-WR-TIMEZONE
  2. TZID
  3. X-LIC-LOCATION

donc je pense que le réglage du fuseau horaire dans le pack devrait être récupéré et il devrait ajouter X-WR-TIMEZONE pour correspondre… lorsque vous importez depuis Google, il suppose votre local… mais chez GoDaddy, je ne trouve pas pour la vie où le régler… et cela fonctionnait avant car je suppose que les anciens calendriers ics avaient des informations de fuseau horaire.

Exemple avec les bonnes informations de fuseau horaire… X-WR-TIMEZONE et X-LIC-LOCATION sont définis et l’événement a DTSTART;TZID=“America/Los_Angeles”:20160206T074400 et DTEND;TZID=“America/Los_Angeles”:20160206T084400

Je pense qu’au minimum, la correction serait d’ajouter X-WR-TIMEZONE et X-LIC-LOCATION et la spécification correcte devrait permettre à chaque événement d’avoir son propre fuseau horaire de début et de fin… Je suis sûr que vous voyagez en avion et que lorsque vous vous déplacez, les réglages de fuseau horaire s’ajustent s’ils sont correctement définis sur le calendrier.

BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 19.0 MIMEDIR//EN
VERSION:2.0
X-WR-TIMEZONE:America/Los_Angeles
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
SUMMARY:Appointment
LOCATION:Pune
DESCRIPTION:Your appointment Details:\n\nPatient Details:Kou Kul\nKeven\n\nAppointment Type:Counselling (30 min)\n\nThanks.
DTSTART;TZID="America/Los_Angeles":20160206T074400
DTEND;TZID="America/Los_Angeles":20160206T084400
PRIORITY:5
STATUS:CONFIRMED
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

tephen_Hornak
ChristopherCamacho
Matt.Johnson
jacobfetzer

image
image1242×849 36.6 KB

4 « J'aime »
2

Des nouvelles à ce sujet ? Le fichier ics ne contient toujours pas d’informations sur le fuseau horaire. Ainsi, lorsque les utilisateurs importent le fichier ics de Discourse dans leur calendrier, ils obtiennent l’heure incorrecte.

3

Le fichier ics que nous générons suit la spécification iCalendar. Plus précisément, pour l’heure, nous générons des horodatages UTC (code source 1, code source 2) suffixés par Z, qui respectent ce qui suit :

FORM #2 : HEURE UTC

      L'heure UTC, ou heure absolue, est identifiée par un caractère suffixe Z majuscule, le désignateur UTC, ajouté à la valeur de l'heure. Par exemple, ce qui suit représente 07h00 UTC :

       070000Z

      Le paramètre de propriété « TZID » NE DOIT PAS être appliqué aux propriétés TIME dont les valeurs d'heure sont spécifiées en UTC.

Les autres propriétés X-WR-TIMEZONE et X-LIC-LOCATION ne font pas partie de cette spécification.

Suite au sujet original dans le premier message, je vois que d’autres ont noté dans un sujet connexe que ce problème est spécifique à la vue calendrier de godaddy. C’est peut-être un problème avec la façon dont il est géré dans leur adaptateur lors de l’importation de fichiers ical. Avez-vous remarqué ce problème avec d’autres calendriers ?

1 « J'aime »
5

L’identifiant de fuseau horaire TZID fait partie de cette spécification RFC 5545 - Internet Calendaring and Scheduling Core Object Specification (iCalendar)

6

Oui, je comprends cette partie. Il est également indiqué dans la même spécification :

Le paramètre de propriété « TZID » NE DOIT PAS être appliqué aux propriétés DATE et aux propriétés DATE-TIME ou TIME dont les valeurs temporelles sont spécifiées en UTC.

Nos horodatages sont spécifiés en UTC, par conséquent, la propriété TZID ne doit pas être appliquée.