Co drugi wtorek, ale według którego zegara? Projekt cyklicznych terminów
Projekt cyklicznych terminów: czytelna reguła, strefa czasu, pojedynczy wyjątek i zakres zmiany. Przykład konsultacji z podglądem rzeczywistych dat.

W tym artykule
„Co drugi wtorek” brzmi wystarczająco dokładnie, dopóki jedna osoba nie zapisze drugiego wtorku miesiąca, a druga spotkań w odstępach dwóch tygodni. Obie reguły mogą przez chwilę wskazywać ten sam dzień. Pierwszy termin się zgadza. Dopiero później okazuje się, że uczestnicy należą do dwóch różnych wersji listopada.
Projektowanie cyklicznych terminów zaczyna się od znaczenia powtórzenia. Pojedyncza poprawna data nie dowodzi, że seria odpowiada zamiarowi. Potrzebne są punkt rozpoczęcia, rytm, koniec i zasady odstępstwa. Do tego dochodzi zegar, według którego zachowujemy porę spotkania. Inaczej łatwo zaprojektować przycisk, który konsekwentnie powtarza nieporozumienie.
Weźmy fikcyjną pracownię sitodruku prowadzącą osiem konsultacji online. Początek: wtorek 3 listopada 2026, godzina 9:00 według Warszawy. Kolejne konsultacje odbywają się co dwa tygodnie. Jeden termin będzie przesunięty z powodu przerwy pracowni, a część osób dołącza z Korei. Grudniowa korekta ma zachować pozostałe konsultacje, a uczestnik w Seulu musi rozpoznać swoją godzinę każdego spotkania.
Najpierw pokaż, jakie daty wynikają ze zdania
Zamiast „Powtarzaj: co drugi wtorek” wybierz czytelne części: co dwa tygodnie, we wtorek, od wskazanej daty. Użytkownik powinien rozumieć, że początek ustala rytm. Zmiana pierwszego wtorku o tydzień może przesunąć wszystkie kolejne spotkania, chociaż pola „co dwa tygodnie” i „wtorek” pozostaną takie same.
W podglądzie naszego przykładu zobaczymy 3 i 17 listopada, 1, 15 i 29 grudnia, a w 2027 roku 12 i 26 stycznia oraz 9 lutego. To osiem wystąpień razem z pierwszym. Pokazanie rzeczywistych dat pozwala zauważyć grudniowy termin jeszcze przed zapisem. Sam opis reguły nie pokazuje, na które święta i przerwy może ona trafić.
Nie trzeba wyświetlać od razu wielkiego kalendarza. Przy ośmiu konsultacjach krótka lista bywa wystarczająca. Przy długiej serii pokaż najbliższe wystąpienia i możliwość obejrzenia dalszych, z jasno określonym zakresem podglądu. Trzy widoczne daty nie powinny sugerować, że seria kończy się na trzeciej.
Instrukcja Google Calendar dotycząca wydarzeń cyklicznych prowadzi przez wybór częstotliwości i końca powtarzania. Przy późniejszej edycji wymaga wskazania, których wydarzeń serii dotyczy zmiana. Reguła i zakres poprawki są osobnymi decyzjami.
W naszym produkcie etykieta „Osiem spotkań” powinna od razu wyjaśniać, czy obejmuje właśnie wpisywane pierwsze. „Powtórz osiem razy” może sugerować dziewięć terminów: jeden początkowy i osiem następnych. Podsumowanie z policzoną listą usuwa tę niepewność lepiej niż dodatkowy techniczny skrót.
Koniec wyznaczony datą wymaga podobnej uwagi. Jeżeli wybierzemy „do 9 lutego włącznie”, ostatnie spotkanie powinno być rozpoznawalne w podglądzie. Nie pokazuj tylko daty granicznej bez wyjaśnienia, czy dzień należy do serii. Przy zmianie początku lub częstotliwości ponownie wylicz wynik, zanim użytkownik zapisze ustawienie.
Dobór samej kontrolki opisuje projekt pola daty i kalendarza. Tutaj do poprawnie wpisanej daty dokładamy znaczenie całej serii. Wygodne wskazanie wtorku nie odpowie jeszcze na pytanie, czy konsultacje kończą się po ośmiu spotkaniach, czy po ośmiu tygodniach.
Godzina prowadzącej i godzina uczestnika mają różne zadania
Dla pracowni przyjmujemy stałą lokalną porę w Warszawie. To organizatorka chce zaczynać o 9:00. Uczestnik w Seulu powinien widzieć odpowiadający temu moment w swojej strefie, lecz jego ustawienie wyświetlania nie powinno samodzielnie przesuwać całej serii. W interfejsie rozdziel strefę reguły od strefy, w której ktoś ogląda daty.
Dokumentacja Google Calendar o kalendarzach i wydarzeniach wskazuje, że dla wydarzeń cyklicznych trzeba określić jedną strefę, w której rozwijane są wystąpienia. Osobno opisuje przeliczanie prezentowanych wyników do wybranej strefy.
Na ekranie wystarczy zrozumiały opis, na przykład „9:00 czasu Warszawy”. Przy wyborze strefy wykonawca potrzebuje jej jednoznacznej reprezentacji. Nie zastępuj jej na stałe różnicą „plus jedna godzina”, jeśli reguła ma zachowywać lokalną porę także po zmianie czasu. Nazwa miasta powinna odpowiadać rzeczywiście używanej strefie, a nie być dekoracją obok technicznie innego ustawienia.
Można porównać dwa kontrolne wystąpienia po obu stronach jesiennej zmiany czasu w 2026 roku. We wtorek 20 października 9:00 w Warszawie odpowiada 16:00 w Seulu; we wtorek 3 listopada 9:00 w Warszawie odpowiada 17:00 w Seulu. To kontrolny przykład przeliczenia dla tych dwóch dat i użytych stref. Stała pora prowadzącej nie oznacza stałej pory każdego uczestnika.
Jeśli użytkownik podróżuje, pokaż, czy zmienił tylko widok, czy regułę spotkań. Przejście na telefon z inną strefą może zmienić sposób prezentacji, ale nie powinno po cichu zmieniać uzgodnienia pracowni. Po powrocie do ustawień nadal musi być rozpoznawalna strefa, według której powstaje seria.
Przy współpracy Polski z Azją ma to praktyczny skutek dla godzin pracy. Uczestnik powinien móc obejrzeć przyszłe terminy u siebie. Nie wystarczy przeliczyć pierwszy i dopisać, że pozostałe będą takie same. Najbardziej użyteczny podgląd obejmie także moment zmiany różnicy między regionami.
Grudniowy wyjątek nie musi przepisać stycznia
Pracownia chce przesunąć konsultację z wtorku 29 grudnia na środę 30 grudnia, zachowując 9:00 w Warszawie. Kolejna nadal ma przypaść 12 stycznia. Na ekranie edycji trzeba nazwać obiekt zmiany: to jedno spotkanie, a nie nowy początek rytmu co dwa tygodnie.

Przewodnik Google Calendar API o wystąpieniach opisuje wyjątek jako zmianę pojedynczego wystąpienia. Pole pierwotnego początku identyfikuje je w serii także wtedy, gdy zostało przełożone na inną godzinę. Tożsamość spotkania nie znika wraz z przeniesieniem.
W naszym podglądzie można pokazać „30 grudnia — zamiast 29 grudnia”. Dzięki temu uczestnik rozpozna przesunięcie, zamiast uznać środę za dodatkowe spotkanie. Liczba konsultacji nadal wynosi osiem. Jeśli produkt pozwala dodać dziewiąte, to inna czynność i inny komunikat. Wyjątek, dodanie oraz odwołanie nie powinny mieć tej samej etykiety „Zmień termin”.
Przy odwołaniu jednego spotkania rozstrzygnij, czy liczba planowanych konsultacji maleje, czy pracownia proponuje zastępstwo. Sam mechanizm kalendarza nie decyduje o warunkach usługi. W naszym przykładzie organizatorka może wskazać dzień zastępczy, lecz ekran nie powinien tworzyć go automatycznie bez przyjętej reguły.
Podobnie zmiana „od tego spotkania” wymaga czytelnej granicy. Gdy od 12 stycznia przechodzimy na 10:00, listopadowe i grudniowe terminy powinny zachować swój opis. Przed zapisem pokaż datę pierwszego zmienianego spotkania oraz nową godzinę. Samo słowo „przyszłe” zależy od chwili odczytu i nie jest wystarczającym identyfikatorem zakresu.
Jeżeli godzinę poprawia się bez opuszczania kalendarza, edycja w miejscu musi uwzględniać wybór zakresu. Opuszczenie małego pola nie powinno automatycznie zmieniać wszystkich spotkań, zanim użytkownik wskaże, czego dotyczy poprawka. Najpierw pokazujemy projektowaną zmianę oraz zakres, dopiero potem potwierdzony zapis. Szybkość małego edytora nie usprawiedliwia ukrycia skutku.
Przy poprawce całej serii trzeba uwzględnić istniejące wyjątki. Czy grudniowa środa zostaje, dostaje nową godzinę, czy wraca do wtorku? To jedna z decyzji, które należy ustalić z wykonawcą przed narysowaniem potwierdzenia. Pokaż użytkownikowi skutek wybranego wariantu. Przyciskiem „Zapisz wszystko” nie rozstrzyga się uczciwie trzech różnych interpretacji.
Przy usuwaniu obowiązuje ta sama granica: jedno wystąpienie, wskazana dalsza część albo cała seria. Odwołanie grudniowej konsultacji nie powinno usuwać styczniowych. Jeżeli produkt oferuje cofnięcie, powrót musi odtworzyć właściwe spotkanie wraz z rozpoznawalnym związkiem z serią. Utworzenie obok nowego wydarzenia o podobnej nazwie nie musi przywrócić wcześniejszych uczestników ani ich ustaleń. Ten rezultat trzeba sprawdzić osobno.
Miesiąc nie jest jednakowym pudełkiem na dni
Drugi wariant usługi obejmuje konsultację trzydziestego pierwszego dnia miesiąca. Nie jest to to samo co ostatni dzień miesiąca. Gdy w podglądzie brakuje lutego, projekt nie powinien sam wybierać między ostatnim dniem tego miesiąca, początkiem marca i pominięciem spotkania. Najpierw potrzebna jest zasada usługi oraz zgodny z nią sposób obliczania.
RFC 5545 w części o regułach powtarzania określa, że wygenerowane niepoprawne daty są pomijane i nie liczą się do zbioru wystąpień. Podaje też przykład pominięcia trzydziestego lutego. To zachowanie formatu iCalendar, nie automatyczna polityka każdej usługi.
Jeżeli produkt proponuje „ostatni dzień miesiąca”, pokaż w podglądzie rzeczywiste końce różnych miesięcy. Jeśli proponuje „31. dzień”, nazwij skutek w miesiącach, które go nie mają. Nie obiecuj spotkania co miesiąc na podstawie reguły, która w części miesięcy niczego nie generuje. Odbiorca kupuje albo planuje konkretne terminy, a nie ćwiczenie z długości miesięcy.
Także „ostatni dzień roboczy” wymaga definicji. Same dni od poniedziałku do piątku nie uwzględniają wszystkich przerw pracowni ani lokalnych świąt. Jeśli kalendarz usługi zawiera własne wyłączenia, powinny być widoczne w wyniku. Projektant nie musi tworzyć tej logiki na makiecie; musi jednak wiedzieć, skąd pochodzą daty, które pokazuje jako dostępne.
Powtórzenie terminu nie rezerwuje jeszcze zasobu
Dobra reguła może wygenerować terminy kolidujące z salą albo dostępnością prowadzącej. To osobny etap od rozumienia cyklu. Jeśli zapis wymaga sprawdzenia każdej daty, pokaż wynik także wtedy, gdy zajęte jest tylko jedno z ośmiu spotkań. Nie nazywaj całej serii zarezerwowaną na podstawie pierwszego wolnego wtorku.
Ocena planowania kalendarza przez AI rozwija kontrolę ograniczeń i odróżnienie propozycji od rezerwacji. Tutaj użytkownik sam wybiera regułę. Podgląd ma mu pokazać jej sens, a stan zapisu powiedzieć, które terminy rzeczywiście zostały przyjęte. Zapisany szkic cyklu nadal może wymagać potwierdzenia dostępności.
Gdy nie uda się zapisać zmiany, pozostaw czytelne porównanie: dotychczasowy termin i proponowana poprawka. Użytkownik powinien wiedzieć, czy konsultacja nadal odbywa się we wtorek, czy już w środę. Jeżeli mechanizm może przyjąć tylko część terminów, pokaż wynik dla każdej przyjętej i odrzuconej pozycji. Przycisk ponowienia ma dotyczyć brakującej czynności, nie bezwiednie tworzyć drugi komplet zaakceptowanych wcześniej spotkań.
Po powrocie do strony ponownie odczytaj zapisany wynik. Kontrolną próbę przeprowadź na jednym charakterystycznym wyjątku oraz dwóch sąsiednich spotkaniach. Przełożona środa powinna pozostać środą, a kolejne wtorki zachować rytm. Taki zestaw szybko ujawni, czy poprawiono tylko podgląd, czy rzeczywistą serię, oraz czy zakres zmiany nie objął dodatkowych dat.
Po zmianie wyjaśnij również los wcześniejszych informacji. Czy uczestnicy dostaną powiadomienie o jednym przełożeniu, czy nowy komplet terminów? W ustawieniach powiadomień trzeba odróżnić drobne aktualizacje od informacji potrzebnej do udziału. Jedna poprawka nie powinna wyglądać jak osiem niezależnych zaproszeń do nowej usługi.
W Aeneia Design można przygotować taki wybór wraz z wyjątkami, potwierdzeniem i opisem zachowania dla wykonawcy. Do rozmowy przynieś jedną rzeczywistą regułę oraz przypadek, w którym trzeba od niej odstąpić. Najwięcej wyjaśni porównanie listy terminów przed poprawką i po niej. Grudniowa środa ma pozostać rozpoznawalnym wyjątkiem, zamiast samowolnie przeprowadzać cały styczeń na nowy plan.
