Ce face și ce nu face iCal

Ce este, concret

iCal e un format de fișier pentru calendare. Fiecare platformă îți dă o adresă web privată, iar la adresa aceea publică un fișier care spune ce intervale sunt ocupate. Oricine are adresa poate citi fișierul.

Sincronizarea prin iCal înseamnă că două sisteme își dau reciproc adresele astea și se citesc unul pe altul periodic. Nu e o legătură vie între ele: e un fișier lăsat într-un loc public și cineva care trece să se uite din când în când.

Ce nu găsești niciodată într-un fișier iCal

Fișierul spune că apartamentul e ocupat între două date. Atât. Nu conține:

• Tarifele. Dacă schimbi prețul pe Airbnb, iCal nu îl duce pe Booking.com. Prețurile rămân treaba ta, în fiecare loc separat, dacă nu ai altceva.
• Restricțiile de sejur. Sejur minim, zile de sosire permise, reguli de weekend — niciuna nu circulă prin iCal.
• Datele oaspetelui. Nume, contact, număr de persoane, ora de sosire: nimic. Din calendarul importat nu ai cu cine să vorbești.
• Banii. Cât s-a încasat, ce comision s-a reținut, când vine plata — nimic din toate astea.

De aici vine cea mai frecventă neînțelegere: un proprietar leagă calendarele prin iCal, vede că datele se închid, și presupune că „e totul sincronizat". Nu e. E sincronizată o singură dimensiune din patru.

De ce întârzierile se adună

Partea asta explică majoritatea suprarezervărilor apărute în ciuda sincronizării.

Ca o rezervare de pe platforma A să închidă nopțile pe platforma B, trebuie să se întâmple două lucruri, unul după altul:

• Platforma A trebuie să își actualizeze fișierul. Nu o face în secunda în care intră rezervarea; o face pe ciclul ei. În industrie se vorbește despre cicluri de ordinul a două-trei ore.
• Cineva trebuie să citească fișierul actualizat. La noi, importul iCal verifică implicit din oră în oră, iar intervalul se poate seta între 15 minute și 24 de ore.

Cele două nu se suprapun. Dacă platforma A își reface fișierul la două ore după rezervare și tu îl citești la o oră după asta, nopțile se închid pe platforma B la trei ore după ce s-au ocupat în realitate. În tot intervalul ăsta, altcineva poate rezerva aceleași nopți.

Nu e o defecțiune și nu se repară cu setări mai agresive: e felul în care funcționează un fișier citit periodic. Ce faci când s-a întâmplat deja.

Când iCal e alegerea corectă

Cu toate limitele de mai sus, iCal își are locul lui, și e un loc real:

• Când nu există conexiune directă. Pentru orice sistem cu care nu ne legăm direct, dar care publică un calendar, iCal e singura punte disponibilă. Mai bine o punte lentă decât niciuna.
• Pentru blocări care vin din altă parte — de exemplu perioadele în care folosești tu apartamentul, ținute în alt calendar.
• Ca plasă de siguranță lângă o conexiune directă, nu în locul ei.

Iar pentru Booking.com și Airbnb, unde o conexiune directă la platformă chiar există, aceasta e mai strânsă decât iCal și duce și tarifele, nu doar datele.

Cazul 999.md

Merită spus separat, pentru că în Moldova e cazul cel mai frecvent și pentru că răspunsul nu e iCal.

999.md nu publică un calendar. Nu e o limitare a iCal, e absența completă a lucrului pe care iCal l-ar citi. O rezervare venită de acolo, sau dintr-un mesaj direct, nu ajunge nicăieri singură, indiferent ce sincronizări ai configurat în rest.

Practic: rezervarea aia se trece o singură dată în calendarul tău unic, imediat. De acolo încolo, nopțile se închid singure pe Booking.com și pe Airbnb. Pasul manual rămâne unul singur, la intrare, în loc de trei, în trei locuri.